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Abstract 


The  Strategic  Mobility  21  (SM21)  program  is  currently  in  the  process  of  developing  the  Joint 
Deployment  and  Distribution  Support  Platform  (JDDSP)  concept,  which  includes  the 
development  of  a  supporting  Global  Transportation  Management  System  (GTMS).  The 
development  of  the  GTMS,  within  the  context  of  an  experiment,  is  considered  the  initial 
operating  capability  of  the  broader  JDDSP  project.  The  development  of  the  JDDSP  is 
structured  within  a  multi-phase  project  designed  to  evaluate,  develop,  and  implement  solutions 
to  challenges  facing  dual-use  distribution  networks:  that  is,  transportation  networks  that  are 
useful  for  military  and  commercial  sectors. 

The  GTMS  experiment,  with  the  support  of  Dole  Foods,  is  focused  on  the  development  of  an 
integrated  System-of-Systems  (SoS)  solution  (that  is  a  combination  of  different  systems).  The 
architecture  used  will  be  based  on  Service  Oriented  Architecture  (SOA).  This  architecture  is 
basically  an  approach  that  provides  for  the  use  of  the  Internet  as  an  Enterprise  Service  Bus  where 
various  systems  exchange  data  using  standard  protocols.  Since  the  system  is  targeted  for  use  by 
multiple  commercial  and  military  customers,  it  will  be  provided  in  the  form  of  Software-as-a- 
Service  (SaaS),  whereby  a  vendor  can  provide  the  user  with  the  appropriate  Internet  access  to  the 
service,  and  the  service  is  maintained  by  a  central  source.  Security  would  be  provided  by 
standard  protocols  used  on  the  Internet  that  have  been  successful  with  secured  applications. 

Because  development  will  be  incremental,  a  spiral  development  model  is  being  used. 
Development  is  being  performed  on  an  open  source  platform.  This  type  of  platform  will  provide 
the  optimal  flexibility  in  interfacing  with  various  types  of  systems. 

The  experiment  with  Dole  will  use  separate  data  sources  for: 

•  Initiating  the  shipment  and  customer  orders 

•  Moving  the  shipment  over  the  ocean 

•  Moving  the  shipment  through  Customs  and  other  regulatory  agencies 

•  Moving  the  shipment  on  rail 

•  Managing  inventory  in  the  warehouse. 

The  experiment  is  meant  to  be  of  limited  scope  in  the  numbers  of  shipments,  the  distribution 
centers  involved,  and  the  number  of  distribution  lanes  involved.  The  data  collected  throughout 
the  experiment  will  be  processed  based  on  various  data  messaging  formats,  which  will  provide 
the  status  of  the  shipment  being  monitored. 

Upon  completion  of  the  experiment,  a  lessons  learned  will  be  developed  and  the  next  phases 
identified  within  the  GTMS  system  transition  report. 
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SECTION  A.  BUSINESS  ENVIRONMENT 


1  INTRODUCTION 

The  Strategic  Mobility  21  (SM21)  program  is  currently  in  the  process  of  developing  the  Joint 
Deployment  and  Distribution  Support  Platform  (JDDSP)  concept,  which  includes  the 
development  of  a  supporting  Global  Transportation  Management  System  (GTMS).  The 
development  of  the  GTMS,  within  the  context  of  an  experiment,  is  considered  the  initial 
operating  capability  of  the  broader  JDDSP  project.  The  development  of  the  JDDSP  is 
structured  within  a  multi-phase  project  designed  to  evaluate,  develop,  and  implement  solutions 
to  challenges  facing  dual-use  distribution  networks:  that  is,  transportation  networks  that  are 
useful  for  military  and  commercial  sectors. 

The  intent  is  to  develop  an  integrated  solution  to  solve  the  most  critical  issues  facing  military 
force  deployment  and  sustainment  distribution  and  commercial  intermodal  logistics.  This 
integrated  solution  is  being  designed  to  transform  logistics  networks  into  agile  enterprises 
through  the  introduction  of  information  technology-based  concepts  and  capabilities  that  promote 
total  end-to-end  visibility  of  shipment  assets  and  the  individual  items  inside  the  asset.  Creating 
this  integrated  solution  requires  unprecedented  levels  of  collaboration  and  data  and  information 
sharing,  to  achieve  the  required  dual-use  end  states  in  a  secure  and  scalable  environment  to 
mitigate: 

•  Regional  congestion, 

•  Community  environmental  impacts,  and 

•  Military-commercial  goods  movement  conflict. 

The  general  concept  is  based  on  a  System-of-Systems  (SoS)  approach  that  will  be  enabled  by 
information  technology  based  services  and  capabilities.  The  goal  of  SM21  is  to  alleviate  the 
problems  of  heterogeneity,  interoperability,  and  requirements  volatility.  The  SM21  architecture 
will  provide  a  platform  for  building  the  next  generation  of  supply  chain  application  services  that 
are  loosely  coupled,  location  transparent,  and  protocol  independent. 

1.1  Incremental  Development  -  Spiral  Model 

The  nature  of  the  overarching  JDDSP  project  is  to  provide  incremental  progress  while 
demonstrating  functionality  at  the  end  of  the  various  phases.  As  a  result,  the  GTMS 
development  process  will  mirror  that  approach,  using  a  spiral  development  model. 

The  spiral  development  model  is  a  systems  development  method  (SDM)  that  combines  aspects 
of  both  design  and  prototyping  for  use  in  large  complex  projects.  There  are  four  (4)  basic  phases 
of  the  spiral  development  model: 

•  Determine  the  Objectives 

•  Identify  and  Resolve  Risks 

•  Development  and  Test 

•  Planning  of  the  Next  Spiral  Iteration. 

As  depicted  in  the  figure  below,  the  spiral  development  method  progresses  through  several 
iterations  until  a  release  of  an  operational  prototype.  The  initial  increment  is  a  cooperative 
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endeavor  with  Dole  Package  Foods  (DPF).  This  increment  is  discussed  in  more  detail  later  in 
this  document. 
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Figure  1 :  Spiral  Development  Model 


2  SUPPLY  CHAIN  MANAGEMENT  OVERVIEW 

The  supply  chain  is  the  model  for  the  system  under  development  by  SM21  program.  Figure  2: 
SCOR  Reference  Model  &  presents  a  general  overview  of  the  Supply  Chain  Operations 
Reference  (SCOR)  Reference  Model.  The  current  GTMS  is  focused  on  the  Shipping  aspects  of 
the  Deliver  function  as  presented  by  the  model.  In  future  releases,  the  GTMS  will  include 
Terminal  Operations,  Drayage,  Transportation  Management  and  Global  Trade  Compliance. 
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Figure  2:  SCOR  Reference  Model  &  GTMS 


2 


3  GENERAL  ENVIRONMENT  OF  LOGISTICS  MANAGEMENT 

Figure  3:  Social  Graph  for  Global  Logistics  represents  the  major  aspects  of  Logistics 
Management.  There  is  not  hierarchy  between  these  three  operations.  In  fact,  each  of  these 
operations  is  generally  managed  independently  of  each  other.  However,  they  share 
interdependent  relationships,  since  an  act  in  one  can  affect  the  operation  in  the  other. 


Figure  3:  Social  Graph  for  Global  Logistics 


•  Global  Trade  Operations  -  Those  entities  interested  in  the  actual  trade  in  goods.  Include  in 
this  group  would  be  the  Doles,  International  Papers  and  IBMs  of  the  world  who  are  interested 
in  moving  goods  because  of  the  acquisition,  sale,  or  production  of  goods. 

•  Multi-Modal  Terminal  Operations  -  These  operations  consists  of  the  nodes  of  the 
transportation  system.  While  the  designation  may  indicate  multi-modal,  for  the  purposes  of 
this  document,  we  will  include  any  transportation  node,  including  consolidation,  multi-modal 
(as  in  sea  to  land,  air  to  land,. . .),  etc.  The  emphasis  is  in  the  management  of  an  intersection 
in  the  transportation  network  and  the  need  to  manage  the  traffic  efficiently  and  effectively. 

•  Global  Transportation  Operations  -  These  operations  are  the  legs  between  the  nodes. 

They  represent  the  companies  responsible  for  the  actual  movement  of  the  goods.  Included 
are  the  land,  sea,  or  air  conveyors  of  goods. 


Below  are  examples  of  some  of  the  considerations  for  each  of  the  different  type  operations: 
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The  problem  with  today’s  systems  is  that  there  are  individual  systems  for  each  of  these  functions. 
In  some  cases,  there  are  multiple  systems.  They  vary  from  organization  to  organization,  even 
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within  the  same  type  organization.  In  the  case  of  Container/  Goods  Location,  there  are  separate 
systems  for  Land,  Sea,  and  Air.  Furthermore,  none  of  the  programs  talks  to  the  other.  In 
addition,  there  is  significant  manual  effort  required  to  work  across  these  diverse  applications. 


4  THE  MILITARY  ENVIRONMENT 

The  military  faces  all  the  same  complexities  of  the  commercial  sector  related  to  logistics  and 
supply  chain  management  with  the  added  complexity  of  highly  dynamic  distribution  networks 
and  demand  patterns.  The  military  is  faced  with  the  need  to  be  able  to  rapidly  deploy  and  sustain 
large  military  forces  to  unknown  locations  with  minimal  planning  and  preparation  time.  To  be 
truly  effective  and  responsive  to  the  combatant  commander,  the  GTMS  operating  within  the 
SO  A  framework  will  need  to  be  integrated  with  the  primary  military  systems  depicted  below  in 
Figure  5. 

Currently  the  combination  of  incomplete  integration  with  commercial  systems  and  stove-piped 
military  systems  prevents  and  outdated  business  processes  prevent  dynamic  planning  and 
replanning  for  force  deployment  and  agile  sustainment  networks.  A  graphical  example  is 
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provided  in  Figure  6  of  the  impact  of  the  current  force  deployment  process  on  commercial  ports 
as  compared  to  the  SM21  GTMS  supported  Agile  Port  System  modeling  results. 


Figure  5:  Military  Systems  -  Future  Integration 


The  light  blue  area  in  the  figure  below  depicts  the  actual  required  buildup  of  forces  on  the  Port  of 
Savannah’s  Ocean  Terminal  over  a  14  day  period  during  a  deployment  to  Iraq. 
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Figure  6:  Force  Deployment  Current  Compared  to  Agile  Port  System 

The  current  lack  of  system  integration  requires  that  all  equipment  be  physically  on  the  port  and 
seen  before  ship  load  planning  is  completed.  This  creates  a  significant  impact  on  both 
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commercial  commerce  and  the  duration  of  military  deployment  timelines.  Extended  deployment 
timelines  increases  risks  for  the  combatant  commander.  Often  overlooked  in  discussions 
surrounding  the  current  deployment  processes  and  information  management  systems  is  the 
impact  on  the  military  members  and  their  families  who  are  about  to  be  deployed,  separated,  and 
faced  with  many  challenging  moments.  Instead  of  moving  equipment  and  waiting  on  the  next 
step  to  take  place  while  information  management  systems  catch  up  they  need  all  the  time  they 
can  get  for  unit  team  building  and  preparing  their  families  for  the  long  separation. 

The  Agile  Port  System  Architecture  contained  in  a  separate  technical  report  provides  more 
details  on  how  the  GTMS  will  support  both  force  deployment  and  sustainment  distribution. 

5  DEFINING  THE  PROBLEM 

In  the  brief  discussion  above  on  global  logistics,  some  specific  parameters  develop: 

•  Overlapping  requirements  -  especially  data 

•  Diverse  sources  of  data 

•  Diverse  needs  for  services  -  driven  by  business  needs 

•  Mature  services  supporting  various  operations 

•  Need  to  integrate  existing  services  to  provide  more  efficient  operations 

5.1  Overlapping  Requirements  -  Especially  Data 

Different  companies  use  different  systems,  and  different  types  of  operations  use  different  types 
of  systems.  However,  the  common  theme  is  that  they  use  the  same  data.  More  importantly, 
where  operations  work  with  each  other,  it  would  be  highly  beneficial  for  them  to  be  seeing  the 
same  data  at  the  same  time,  even  if  they  are  looking  at  the  data  differently. 

5.2  Diverse  Sources  of  Data 

For  a  large  organization  moving  product  internationally,  the  list  of  potential  data  sources  will 
include,  as  a  minimum,  each  sea  shipper,  each  terminal,  each  rail,  each  trucking  firm  as  well  as 
customs.  As  the  shipment  moves  from  one  mode  to  the  next,  the  status  and  sequencing  of  data 
needs  to  be  maintained,  even  if  a  prior  event  is  reported  after  the  second  event.  Multiple  sources 
mean  multiple  formats  that  need  to  be  reconciled.  In  addition,  this  information  must  be 
effectively  and  efficiently  available  to  the  various  operations  of  the  organization. 

5.3  Diverse  Needs  for  Services  -  Driven  by  Business  Needs 

Services  are  dependent  on: 

•  Type  of  operation  being  supported 

•  Individual  organization  supporting  the  operation 

•  Individual  manger  of  the  operation 

Each  type  of  operation,  global  trade,  multi-modal  terminal  operation,  or  global  transportation, 
focuses  on  different  requirements.  But  even  within  these  operations,  the  history  of  the  company, 
the  previous  systems,  or  even  the  general  culture  can  change  the  service  requirement.  Finally, 
individual  mangers,  especially  at  the  higher  levels  will  demand  to  see  the  information  in  formats 
that  work  for  them.  A  universal  approach  would  assume  that  there  is  one  best  way  to  do  things. 
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It  would  assume  that  there  would  be  no  need  for  improvement.  It  would  deny  the  individual 
management  differences  that  provide  an  edge  for  the  organization. 

5.4  Mature  Services  Supporting  Various  Operations 

In  many  organizations,  there  may  be  systems  that  have  been  used  over  the  years  or  have  been 
developed  over  time  that  represent  some  best  practices  for  that  particular  operation.  While  a 
wish  to  improve  the  overall  operation  may  be  highly  desired,  it  may  not  be  acceptable  to  lose 
specific  systems  that  are  considered  critical. 

5.5  Need  to  Integrate  Existing  Services  to  Provide  More  Efficient  Operations 

Many  organizations  have  operations  and  systems  that  work  well  but  need  enhancing  or  further 
“integration”.  In  other  cases,  there  are  manual  operations  that  could  be  replaced  with 
automation,  if  someone  could  figure  out  how  to  do  it.  Even  if  new  logistics  applications  could 
replace  the  current  applications  being  used  by  the  company,  there  may  be  internal  management 
systems  that  need  to  be  integrated  in  some  form.  At  a  minimum,  the  desire  to  transition 
gradually  may  dictate  which  new  applications  or  services  are  applied  over  time. 

6  PROPOSED  SOLUTION 

6.1  Data  Integration 

If  the  most  common  resource  across  operations  is  the  data,  then  the  first  step  is  to  make  the  data 
available  in  a  common  form.  That  would  mean  acquiring  the  data  from  the  various  sources,  then 
normalizing  and  organizing  it.  Normalize  means  pulling  the  data  from  the  various  sources  with 
various  formats  and  making  the  format  of  the  data  consistent  so  that  it  can  be  processed  and 
reviewed  efficiently.  Organizing  means  to  take  the  various  recorded  events  for  a  given  shipment 
and  properly  sequence  and  identify  the  appropriate  status  of  that  shipment.  While  many 
organizations  depend  on  following  a  shipment  from  event  to  event  and  mode  to  mode  manually, 
the  ability  to  consolidate  data  provides  a  more  efficient  and  effective  approach  to  managing  the 
process.  It  also  permits  the  development  of  metrics  and  exception  reporting  that  could  not  be 
performed  under  a  manual  process.  Figure  7:  Data  Integration  provides  a  graphic  example  of 
this  approach. 
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Figure  7:  Data  Integration 


6.2  Service  Accessibility 

Given  a  common  repository  of  data,  the  organization  is  now  in  a  position  to  provide  services 
based  on  that  common  data.  As  discussed  earlier,  services  will  depend  on  the  type  operation 
being  performed,  the  organization  performing  the  operation,  and  potentially  the  manager  in 
charge  of  the  operation.  That  means  there  has  to  be  some  diversity  permitted  in  the  types  of 
services  being  provided.  As  a  result,  the  system  under  consideration  should  provide  a  spectrum 
of  data /  information  as  well  as  a  spectrum  of  management  tools.  The  individual  operations 
would  select  the  ones  that  are  most  advantageous  to  its  operation. 

The  next  step  is  to  determine  how  to  address  the  implementation  of  this  approach.  There  is  a 
significant  knowledge  base  built  into  the  existing  transportation  systems  in  the  market  today. 
While  most  generally  represent  smoke-stack  systems  (that  is,  they  have  not  been  integrated  with 
each  other),  it  would  take  a  significant  investment  to  build  a  unified  system,  not  to  mention  the 
experience  curve  the  current  systems  have  already  been  through.  As  a  result,  the  objective  is  to 
provide  a  solution  that  can  tie  these  diverse  applications  together,  while  providing  tools  to  bridge 
the  gaps  between  the  systems. 
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Figure  8:  Global  Logistics  Integrated  Management  Services  shows  a  high  level  architecture  for 
implementing  an  integrated  service.  This  architecture  enables  any  person  to  access  any  service. 
It  allows  any  service  to  respond  to  that  person,  as  well  as  obtain  information  from  the  needed 
data  sources.  The  architecture  also  permits  any  service  to  ask  for  information  from  another 
service.  Furthermore,  legacy  systems  can  provide  their  services  to  the  mix  as  well  by  wrapping 
legacy  applications  in  the  appropriate  message  wrappers.  This  approach  is  basically  a  Service 
Oriented  Architecture  or  SOA. 

6.3  Consolidated  View 

Below  is  a  consolidated  view  of  the  data  collection  and  service  provision.  As  has  been 
discussed,  the  first  objective  is  to  obtain  the  data  from  the  various  sources,  normalize,  and 
organize  it.  The  next  step  is  to  make  it  available  for  the  various  services  needed  by  the 
operation. 
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Figure  9:  Consolidated  View 
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SECTION  B.  ARCHITECTURE 


7  SYSTEM  OF  SYSTEMS  (SOS) 

The  GTMS  is  being  developed  as  a  System  of  Systems  (SoS).  This  concept  takes  into  account 
the  fact  that  there  are  excellent  best-of-breed  systems  that  perform  selected  functions  well.  In 
addition,  there  is  a  need  to  combine  whatever  functionality  the  GTMS  provides  with  functions  in 
the  customer’s  environment  with  which  the  customer  would  want  to  integrate.  The  combination 
of  these  various  capabilities  into  a  common  interface  should  permit  synergies  unachievable  in 
other  manners.  This  combination  also  permits  customers  to  take  advantage  of  an  “ABC” 
philosophy  similar  to  that  used  by  DISA  (Defense  Information  Systems  Agency):  “Adopt- 
before-Buy,  Buy-before-Create.”  In  general,  this  means  that  the  customer  is  taking  advantage  of 
well-developed  capabilities  that  already  exist,  rather  than  trying  to  re-invent  from  scratch  and 
assume  the  risk  of  the  learning  curve  that  comes  with  that  approach. 

8  SOFTWARE  AS  A  SERVICE  (SAAS) 

Software  as  a  Service  (SaaS)  is  a  model  whereby  customers  make  use  of  the  application  as  a 
service  on  demand.  That  means  that  the  service  is  easily  accessible  to  the  customer  through  a 
web  browser,  regardless  whether  the  service  is  hosted  on  a  vendor  web  site  or  the  customer’s 
own  web  site. 

The  GTMS  is  designed  to  use  the  SaaS  model.  This  approach  provides  a  number  of  advantages: 

•  Data  collected  from  various  vendors  on  shipping  can  be  used  by  a  number  of  different 
customers,  e.g.,  the  multi-modal  terminal  operators  and  shippers  would  use  the  same  data  as 
the  supplier  in  tracking  the  shipment.  This  ensures  consistency  of  data  across  operations, 
which  is  especially  useful  when  trying  to  reconcile  shipping  issues. 

•  All  services  will  be  provided  across  the  web,  permitting  suppliers  and  related  vendors  to 
access  the  information  any  place  or  anytime. 

•  Being  a  web  service,  no  updates  need  to  be  distributed  as  services  are  enhanced.  This 
significantly  reduces  the  software  coordination  needed  to  support  the  services. 

•  As  an  organization  is  prepared  to  add  an  additional  capability,  it  is  available  to  all  appropriate 
individuals  upon  release. 

•  To  the  degree  that  closer  cooperation  is  indicated  between  the  shipper  and  supplier  in  the 
future,  a  platform  that  can  be  shared  widely  will  significantly  enhance  the  relationship. 

9  SERVICE  ORIENTED  ARCHITECTURE  (SOA) 

The  GTMS  needs  an  architecture  that  will  support  a  System  of  Systems  (SoS)  and  Software  as  a 
Service  (SaaS).  The  selected  architecture  is  a  Service  Oriented  Architecture  (SOA).  It  is 
designed  to  alleviate  the  problems  of  system  and  operating  environment  heterogeneity  and 
interoperability  as  well  as  the  normal  requirements  volatility  that  exists  in  most  operating 
environments. 
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Think  of  SOA  as  a  collection  of  services  connected  by  a  communication  link  -also  called  a  bus 
(in  the  GTMS  case,  the  Internet).  A  user  is  on  the  web  and  from  the  web  interface,  requests  an 
action.  The  request  is  sent  to  the  proper  service,  which  then  provides  a  response  to  that  request. 
To  facilitate  this  capability,  SM21  has  established  a  single  sign-on  capability  for  the  user  which 
allows  a  smooth  transition  between  the  services  without  the  user  interrupting  their  thinking  with 
an  additional  sign-on  when  crossing  applications. 

The  general  capability  of  the  GTMS  is  obtained  by  using  web-based  standards  that  permit 
communication  in  the  common  environment  -  the  Internet.  These  standard  communication 
protocols  not  only  let  the  user  communicate  with  the  service,  but  they  allow  services  to 
communicate  with  each  other.  That  permits  services  to  be  reused  outside  the  areas  they  would 
normally  operate.  This  approach  also  allows  the  architecture  to  interface  with  any  application 
that  can  form  an  interface  with  the  Internet.  This  capability  permits  older  applications  to  extend 
their  life  while  extending  their  utility.  It  also  permits  any  platform  (mainframe,  mid-frame, 
personal  computer,  server)  and  any  development  environment  (Java,  COBOL,  Microsoft,...)  to 
participate  in  the  operation.  The  most  important  elements  are  the  existence  of  the  service,  a  bus 
(communication  link),  and  an  agreed  protocol  (messaging  format). 


» 1 . 
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Figure  10:  SOA  Architecture  Example 

There  are  many  books  and  papers  written  on  SOA,  and  there  are  many  ways  to  implement  it. 

The  foremost  characteristic,  however,  is  that  the  architecture  is  centered  on  services.  Next,  those 
services  can  be  existing  systems  that  need  to  talk  to  each  other  and  have  not  in  the  past.  In  fact, 
the  first  step  for  any  development  of  SOA  is  to  define  the  requirements,  motivation,  and  goals  for 
pursuing  the  architecture.1  That  makes  it  business  and  process  focused.  A  basic  element  of  SOA 
is  that  the  services  are  loosely  coupled  -  a  service  will  be  requested  via  a  messaging  system  and  a 
response  will  be  returned. 

In  the  case  of  Dole,  the  first  step  was  to  complete  a  value  stream  analysis  to  define  the 
requirements,  potential  motivation,  and  goals  for  developing  the  initial  operating  capability  of 
the  SOA.  After  verification  of  the  analysis  with  Dole  and  their  supply  chain  partners,  five  (5) 
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key  capabilities  were  defined  as  the  initial  features  of  the  GTMS  IOC,  which  will  support 
container  shipment  management: 

•  End-to-End  Shipment  Tracking  and  Visibility 

•  Integrated  Global  Transportation  Management  (GTM) 

•  Automated  Container  Pick-up  Prioritization  and  Scheduling 

•  Exception  Based  Management 

•  Extended  Supply  Chain  Management  Reporting 

The  end-to-end  shipment  tracking  and  visibility  required  that  all  of  the  major  distribution 
components  associated  with  the  Dole  Foods  Supply  Chain  Network  (Figure  11:  End-to-End  Supply 
Chain  Network)  be  seamlessly  integrated.  The  objective  was  to  enable  visibility  across  modes 
(ocean  carrier,  rail,  and  truck)  and  through  the  nodes  (manufacturing  sites,  terminals,  and 
warehouses)  to  allow  information  from  different  data  sources  and  systems  to  be  viewed  in  one 
system  or  dashboard. 


DOLE  FOODS  -  SUPPLY  CHAIN  NETWORK 


Mfg  Sites  and  Ocean  Carriers  Terminals  US  Customs  Rail  Truck  Dole  Warehouse 

Suppliers  USDA  &  FDA 


Figure  11:  End-to-End  Supply  Chain  Network 


The  end-to-end  shipment  tracking  and  visibility  requirement  was  the  most  comprehensive 
requirement  and  established  the  base  capability  for  the  remaining  four  key  capabilities.  To  meet 
this  comprehensive  requirement,  three  existing  best-of-breed  commercial  systems  that  had  not 
previously  exchanged  data  where  integrated  within  the  framework  of  the  SOA  as  outlined  below 
and  depicted  in  Figure  12. 

•  GT  Nexus  -  SaaS  -  Ocean  Carrier  shipment  In-Transit  Visibility 

•  Transentric  -  SaaS-  Rail  Carrier  Shipment  In-Transit  Visibility 

•  One  Network  Enterprises  -  SaaS  -  Transportation  Management  System 
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SM21  JDDSP  SOA  FRAMEWORK 


BEST  OF  BREED  APPLICATIONS 
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Figure  12:  End-to-End  Supply  Chain  Distribution  Visibility  Systems 

After  completion  of  a  successful  user  acceptance  test  with  Dole,  to  fill  in  remaining  capability 
gaps  or  to  enhance  the  fidelity  of  the  initial  operating  capability  of  the  GTMS,  additional  existing 
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systems  will  be  integrated  and  value  added  web  services  will  be  developed.  Drayage  tracking  is 
an  example  of  a  web  service  under  consideration  for  development  and  integration  for  integration. 


Figure  13:  SO  A  Elements2 


Here  are  the  elements  of  a  SOA  for  the  most  elementary  implementation: 

•  Define  the  applications  front  end  -  the  initial  starting  point.  Also  the  point  for 
establishing  single-sign-on  (SSO). 

•  Identify  the  services  to  be  shared. 

•  Identify  where  the  services  are  to  reside.  They  may  reside  in  different  places. 

•  Identify  the  Service  Bus  to  be  used.  This  is  the  infrastructure  that  will  transmit  the 
requests  and  receive  the  responses.  In  the  GTMS  case,  that  would  be  the  Internet. 

In  defining  the  service,  the  following  steps  are  taken: 

•  Define  the  Contract.  The  contract  would  be  the  agreement  on  the  service  that  is  to  be 
provided. 

•  Implement  the  service  -  which  includes: 

o  Business  logic  to  accomplish  the  task, 
o  Data  needed  to  perform  the  service. 

•  Define  the  interface.  The  interface  would  be  the  messaging  used  to  request  the  service 
and  the  messaging  to  obtain  the  result.  Since  the  GTMS  is  using  the  Internet,  the 
messaging  uses  XML  and  HTML. 

Assuming  the  application  exists,  the  addition  of  a  service  requires  adding  an  interface  to  the 
application  that  can  receive  a  request  and  return  an  answer  using  an  agreed  on  messaging 
protocol. 


2  Wikipedia,  "Service  Oriented  Architecture”  with  reference  to  Elements  of  SOA,  by  Dirk  Krafzig,  Karl  Banke 
and  Dirk  Slama.  Enterprose  SOA,  Prentice  Hall,  2005. 
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10  DEVELOPMENT/  OPERATING  ENVIRONMENT 

The  SM21  development  team  has  designed  the  operating  environment  to  provide  the  flexibility 
for  any  system  that  can  interface  with  the  Internet  to  be  able  to  provide  a  service  to  the  GTMS. 
As  a  result,  the  discussion  on  the  Development/  Operating  Environment  is  focused  on  the  SOA 
frontend.  Each  of  the  services  is  expected  to  have  its  own  architecture  with  the  capability  of 
interfacing  with  the  Internet. 

10.1  General  Architecture 

The  objective  of  SM21  is  to  enable  the  most  universal  access  possible.  As  a  result,  the  GTMS 
frontend  exclusively  uses  open  standards  software  in  its  development.  The  selected  technologies 
provide  SM21  with  the  security  and  flexibility  required  to  bring  this  project  through  a  successful 
production  transition.  The  components  used  include: 


RichFaces 

(Javserver  Faces) 
(User  Interfaces) 


JAAS 

(Java  Authentication  & 
Authorization  Service)  ) 


JBOSS 

(J2EE  Platform) 
(Application  Server) 


MySQL 

(Database) 


Figure  14:  The  GTMS  Operating  Environment 

•  Ubuntu  Linux  -  Linux  is  an  open  source  operating  system.  Ubuntu  Linux  is  being 
utilized  as  the  hosting  development  environment.  Ubuntu  provides  a  very  solid  Debian 
(free)  based  Linux  stack  that  provides  all  the  components  needed  to  insure  a  secure  easily 
updated  environment  that  can  run  any  open  source  technology. 

•  Apache2  -  Apache2  is  a  Web  Server  -  The  Apache  has  been  the  most  popular  web  server 
on  the  Internet  since  about  1996. 

•  JBoss  -  JBoss  is  a  J2EE  (Java  2  Enterprise  Edition)  Server.  -  Lucene  and  Jena  are 
dependent  jar  (program)  files  within  JBoss.  The  open  standard-developed  software 
integrates  with  open  standards  tools  to  provide  an  enterprise  solution.  JBoss,  in 
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combination  with  Rich  Faces  and  Java  Server  Faces ,  provides  a  unique  ability  to  rapidly 
develop  and  deploy  user  friendly  front  ends  to  access  and  manipulate  back  end  data. 

•  MySQL  -  MySQL  is  an  ANSI-99  compliant  relational  database.  Open-sourced,  the 
database  can  be  transplanted  at  will  without  licensing  concerns.  At  the  same  time,  it 
provides  the  security  and  flexibility  required  in  business  and  military  environments. 

•  JAAS  (Java  Authentication  and  Authorization  Service)-  provides  the  security  framework 
for  user-centric  security 

•  Lucene  -  Lucene  is  a  text  search  engine  that  provides  a  mechanism  for  lookups  inside 
each  EDI  message  to  include  greospatial  data. 

•  Jena  -  The  enhanced  data  is  sematically  enabled  and  stored  in  Jena,  the  preeminent 
semantic  web  tool.  This  enhanced  data  is  ultimately  read  and  forewarded  to  One 
Network3.  Communication  Protocols 

As  discussed  in  a  previous  chapter,  the  communications  bus  for  the  GTMS  is  the  Internet,  which 
means  the  GTMS  will  adopt  the  communications  protocols  for  the  Internet.  However,  it  must  be 
understood  that  after  messages  are  transmitted,  the  content  of  the  message  must  also  have  a 
format. 

The  GTMS  uses  two  styles  of  software  architecture  for  communication  across  the  web: 

•  REST  -  Representational  State  Transfer 

•  SOAP  -  Simple  Object  Access  Protocol 

Having  both  capabilities  provides  the  GTMS  flexibility  to  connect  with  many  more  systems. 

10.2  REST 

Representational  State  Transfer,  or  REST,  in  general  is  a  group  of  networking  architectural 
principles  that  are  used  to  determine  the  naming  and  addressing  of  resources.  REST  web 
services  use  HTTP  to  transfer  data  without  an  additional  protocol  such  as  SOAP.  The  GTMS 
accomplishes  RESTful  interactions  by  the  web  application  handling  RESTful  URL's  via  a  URL 
Rewrite  Filter  and  through  a  RESTFul  web  service  application.  REST  also  uses  Uniform 
Resource  Indicators  (URL’s  are  a  form  of  URL s)  to  access,  create,  update,  and  delete  data. 

The  data  within  a  RESTFul  interface  may  appear  in  a  variety  of  different  ways.  The  data  may 
appear  as  raw  XML  interpreted  by  the  browser,  or  directly  handled  by  HTML  style  sheets.  The 
data  may  also  appear  entirely  as  a  service  with  no  user  interface.  The  form  of  the  data  within  the 
message  must  be  well-defined  to  ensure  that  the  responder  can  understand  the  request  and  that 
the  response  sent  can  be  understood  by  the  requestor.  This  is  part  of  the  “contract”  discussed  in 
the  Service  Oriented  Architecture  (SOA)  section. 

Some  of  the  proposed  advantages  of  using  RESTful  applications  include: 

•  Improved  response  time  and  reduced  server  load. 

•  Reducing  reliance  on  session  state  information. 

•  Browser  accessible. 


3  This  capability  was  added  on  for  future  development  but  was  not  part  of  the  original  development  request. 
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•  Technology  agnostic. 

10.3  SOAP 

Simple  Object  Access  Protocol,  or  SOAP,  specifies  a  protocol  for  exchanging  data  through  web 
services  over  networks.  Extensible  Markup  Language,  or  XML,  is  the  data  format  and  is  usually 
coupled  with  Remote  Procedure  Call,  or  RPC,  and  HTTP  for  communications.  This  directional 
XML  communication  can  pass  data  between  applications  to  be  interpreted  and  displayed  in  any 
format  needed  by  the  end  user.  The  GTMS  uses  Web  Services  to  automate  the  data  exchange 
mechanism  with  any  capable  enterprise  application  belonging  to  organizational  partners. 

As  discussed  under  REST,  the  form  of  the  data  in  the  message  must  be  well-defined  to  ensure 
that  the  responder  can  understand  the  request  and  that  the  response  sent  can  be  understood  by  the 
requestor.  This  is  part  of  the  “contract”  discussed  in  the  section  on  Service  Oriented 
Architecture  (SOA). 

11  SYSTEM  INTEGRATION 

The  SOA  based  architecture  connects  with  services.  The  GTMS  is  a  System  of  Systems  (SoS), 
which  means  that  the  GTMS  is  targeted  to  provide  services  from  any  source  that  meets  the 
business  needs.  Figure  15:  SOA  Based  Architecture,  on  the  following  page,  gives  an  overview 
of  how  the  various  functions  might  relate.  Please  be  aware  that  the  hardware  and 
communications  platforms  are  not  designated  here.  A  reference  to  a  web  browser  means  any 
web  browser  that  can  handle  Web  3.0  capabilities.  Web  servers  may  be  anywhere.  The  various 
components  of  the  services  layer  are  very  likely  to  be  on  different  servers  provided  by  different 
vendors.  Also,  the  databases  may  or  may  not  need  to  be  accessed  through  an  application  layer. 
Given  that  the  Internet  is  the  main  communication  bus/  protocols  for  all  of  this  activity,  the 
connection  is  now  not  as  important  to  understand  as  the  services  that  are  being  made  available. 

The  SM21  updated  experimentation  plan  outlines  future  web  services  related  to  trade 
classification,  security  compliance,  and  online  analytical  processing  (OLAP)  capabilities  which 
will  be  developed  for  experimentation  and  system  integration.  Likewise,  data  input  in  the  future 
will  use  semantic  web  tools  to  more  completely  automate  data  integration  from  the  many 
possible  sources  and  formats.  Additional  experimentation  is  being  planned  for  cloud  computing, 
advanced  security  enhancements,  and  the  integration  of  real-time  sensor  feeds  that  add  value  to 
the  distribution  management  process  and  control  of  inventory.  Finally,  planning  includes  the 
development  of  a  semantically  enabled  knowledge  management  system  for  shipper  use  that 
would  be  enabled  by  SM21  developed  ontologies  in  the  following  initial  domains:  inventory 
shipment,  trade  and  security  compliance,  warehouse  management,  and  transportation  asset 
management. 

12  SUMMARY 

The  GTMS  is  designed  to  provide  service  on  the  most  ubiquitous  platform:  the  Internet.  It  uses 
Open  Source  resources  that  ensure  the  ability  to  move  the  application  anywhere  without  the  need 
for  licensing  the  underlying  platforms. 

The  GTMS  is  designed  to  incorporate  any  system  where  a  web-interface  can  be  established. 

This  design  permits  any  legacy  or  web-based  system  to  participate  in  the  activity.  The  major 
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advantage  to  the  customer  is  that  their  current  systems  can  be  incorporated  if  desired.  The  value 
in  current  systems  can  be  extended  by  broadening  their  use.  In  addition,  those  systems  can  be 
extended  with  the  value  of  the  integration  from  other  services.  In  general,  the  SM21  program  is 
focused  on  building  a  system  around  the  needs  of  the  customer. 


Figure  15:  SO  A  Based  Architecture 
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SECTION  C.  SYSTEM  SECURITY 


13  CONSIDERATIONS 

In  addressing  the  security  aspects  of  the  system,  the  current  state  of  the  art  programming  for 
Internet  security  was  considered  as  well  as  the  standards  established  in  the  Orange  Book  (named 
after  the  color  of  the  cover  )/  Director  of  Central  Intelligence  Directive  6/3  (DCID-6/3)  entitled, 
“Protecting  Sensitive  Compartmented  Information  Within  Information  Systems”. 

Given  the  nature  of  the  Internet,  the  objective  is  not  to  secure  the  entire  Internet  itself,  but  to 
secure  the  messages  being  sent,  as  well  as  the  physical  entities  at  each  end.  The  goal  is  to  get  the 
message  from  door-to-door  safely  and  uncompromised.  Basically,  the  technology  that  moves 
financial  transactions  across  the  web  is  the  same  as  will  be  used  by  the  GTMS. 

Three  aspects  are  involved  in  security: 

1.  Physical  -  ensure  that  the  servers  and  communication  links  at  the  service  sites  are 
secure. 

2.  Communication  -  ensure  the  transmission  of  the  message  is  secure. 

3.  Administrative  -  provide  an  environment  for  the  proper  administration  of  users  and 
their  respective  roles. 

14  PHYSICAL  SECURITY 

As  a  system  of  systems  (SoS),  the  GTMS  allows  for  services  to  be  provided  by  anyone.  As  a 
result,  the  provider  of  the  service  is  responsible  for  ensuring  the  physical  security  of  their 
service.  Regardless,  the  characteristics  of  the  security  should  include: 

•  Assurance  -  GTMS  hardware  is  located  in  a  protected  area  where  only  authorized 
personnel  are  allowed  entrance.  In  addition  to  this  physical  protection,  the  GTMS 
server(s)  only  allow  access  to  individuals  whose  system  username  and  password  have 
permissions  of  an  appropriate  level  to  access  the  servers  and  code  base.  A  log  of  user 
access  to  the  servers  is  monitored. 

•  Continuous  Protection  -  The  GTMS  servers  are  not  available  to  unauthorized 
personnel.  Access  to  the  source  code  and  system  configuration  is  under  lock  and  key. 

The  GTMS  system  continuously  protects  against  tampering  and/or  unauthorized  changes 
via  password  protection. 

15  COMMUNICATION  SECURITY 

15.1  Characteristics 

In  discussions  of  information  security,  these  topics  are  discussed: 

•  Confidentiality  -  data  is  secured  from  others  between  the  sender  and  designated 
receiver.  The  best  approach  to  this  issue  is  encryption. 
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•  Integrity  -  data  has  not  been  altered  between  sender  and  receiver.  Encryption  functions 
that  include  the  hashing  of  messages  provide  a  validation  that  the  message  has  not  been 
altered  accidently  or  on  purpose. 

•  Authentication  -  origin  of  message  can  be  established.  Passwords  as  part  of  the  sign  on 
establish  the  person  which  is  validated  by  the  application.  However,  as  the  message 
moves  from  one  platform  to  another,  a  transport  layer  security  (e.g.,  the  use  of  the  Secure 
Socket  Layer  (SSL)  in  HTTPS)  sets  up  a  mutual  verification  that  establishes  the 
authentication. 

•  Authorization  -  managing  the  access  to  various  functions.  In  the  case  of  GTMS,  the 
security  is  role  based  and  functions  are  permitted  based  on  the  authentication  of  the 
person. 

•  Non-repudiation  -  sender  cannot  deny  having  sent  the  message.  This  is  a  combination 
of  authentication  and  transaction  logging.  Authentication  identifies  the  individual. 
Transaction  logging  provides  a  record  of  the  activity. 

•  Accessibility  -  Service  is  accessible  at  all  times,  including  from  denial-of-service  (DOS) 
attacks,  from  outside  or  inside  of  the  system  hosting  the  service.  In  the  case  of  the 
GTMS,  this  is  managed  through  the  infrastructure  where  algorithms  identify  potential 
DOS  attacks.  The  other  aspect  is  maintaining  redundancy  in  the  infrastructure  for  servers 
and  power. 

15.2  Required  Capabilities 

Based  on  the  characteristics  outlined  above,  the  GTMS  will  provide  a  security  structure  that 
includes: 

1.  Encryption 

2.  User  Id  &  passwords 

3.  Secured  Socket  Layer  (SSL) 

4.  Role  Based  Authorization 

5.  Transaction  Logging 

15.3  Security  Architecture 

The  architecture  used  by  the  GTMS  core  is  based  on  the  Java  Authentication  and  Authorization 
Service  (JAAS).  JAAS  is  a  Java  security  framework  incorporated  within  the  JBoss  application 
server.  It  includes  a  wide  range  of  capabilities  including  cryptography  (encryption),  public  key 
infrastructure,  secure  communication,  authentication,  and  access  control.  The  JAAS  architecture 
covers  points  1,  2  and  3  in  required  capabilities.  The  approach  for  covering  the  first  three 
required  capabilities  includes: 

15.3.1  Traditional  HTTP  Authentication:  HTTPS 

Secure  socket  layer  (SSL)  is  a  technology  which  allows  Web  browsers  and  Web  servers  to 
communicate  over  a  secured  connection.  The  data  being  sent  is  encrypted  by  one  side,  then 
transmitted,  and  decrypted  by  the  other  side  before  processing.  This  is  a  two-way  process,  where 
both  the  server  and  the  browser  encrypt  all  traffic  before  sending  out  data.  The  trusted  store 
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provides  the  handshake  between  the  browser  and  the  http  server  allowing  encrypted 
communication. 

By  using  J2EE  as  the  target  environment,  single  sign-on  is  activated,  providing  single 
authentication  irrespective  of  how  many  different  web  applications  a  user  accesses. 

This  is  traditional  web  security  with  some  extensions  added  to  prepare  for  full  container  security. 

15.3.2  J2EE:  Enterprise  JavaBeans  Technology  Securing  Enterprise  Java  Beans 
(EJBs) 

Enterprise  JavaBeans  (EJB)  technology  is  the  server-side  component  architecture  for  the  Java  2 
Platform,  Enterprise  Edition  (J2EE)  platform.  EJB  technology  enables  rapid  and  simplified 
development  of  distributed,  transactional,  secure,  and  portable  applications  based  on  Java 
technology. 

To  secure  an  Enterprise  Bean,  the  roles  used  at  the  web  layer  are  leveraged  to  provide  the  same 
type  of  role  based  security  just  at  the  EJB  method. 

15.3.3  Writing  the  Login  Module  and  Principal 

Finally,  it  is  not  hard  to  write  a  login  module.  They  are  typically  50  to  100  lines  in  modules. 

Prior  to  open  standards,  advanced  security  required  writing  hundreds,  if  not  thousands,  of  lines 
of  software.  Using  J2EE  and  JAAS,  most  of  the  work  is  in  the  definitions  contained  in  the  XML 
files. 

16  ADMINISTRATIVE  SECURITY 

16.1  Security  Policy 

The  GTMS  system  enforces  a  well-defined  security  policy.  There  is  a  set  of  rules  that  are  used 
by  the  GTMS  to  determine  whether  a  subject  receives  permission  to  gain  access  to  a  specific 
object.  No  subject  lacking  the  appropriate  clearance  level  is  permitted  access  to  sensitive 
information.  Discretionary  rules  applied  to  selected  subjects  and  groups  of  subjects  control 
access  to  data.  Control  of  the  rule  set  for  system  and  data  access  is  only  allowed  for  users 
authorized  for  such  activity. 

16.2  Mechanics  of  the  GTMS  Security 

16.2.1  Marking 

Roles  are  associated  with  system  objects  and  identify  the  access  level  or  access  limit  associated 
with  the  object. 

16.2.2  Identification 

Users  of  the  GTMS  system  are  uniquely  identified.  Each  identified  user  has  person  and  access 
level  information  associated  with  them.  All  information  pertaining  to  the  user  is  maintained  in  a 
database. 
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16.2.3  Accountability 

The  GTMS  must  maintain  audit  information  so  that  actions  affecting  security  and  information 
integrity  can  be  tracked  to  the  responsible  subject.  Auditing  levels  are  set  to  limit  the  impact  to 
system  performance.  The  audit  date  is  placed  on  two  redundant  password  protected  systems. 

16.3  Role  Management 

Users,  Groups,  and  Roles  are  assigned  through  an  administrator’s  user  interface.  The 
authentication  described  above  is  used  to  adjudicate  access  to  altering  the  Users,  Groups,  and 
Roles  by  requiring  any  user  wishing  to  change  Users,  Groups,  and  Roles  to  posses  the 
"Administrator"  role.  An  initial  Administrative  user  is  available  with  the  caveat  that  the 
Administrative  password  must  be  changed  upon  the  administrator’s  first  successful  login  to  the 
application.  This  user  may  then  be  used  to  create  all  of  the  Users  and  additional  Groups  and 
Roles  required  for  the  GTMS  system  authentication  and  governance. 

•  Roles  consist  of  a  unique  name  and  the  relationships  with  User  and  Group  objects. 
Roles  are  associated  with  Groups  and  Users  by  a  many-to-many  relationship  (Groups 
can  have  many  Roles  and  Roles  may  have  many  Groups). 

•  Groups  consist  of  a  unique  name  and  the  relationships  between  Users  and  Roles. 
Groups  are  associated  with  Roles  and  Users  by  a  many-to-many  relationship. 

•  Users  consist  of  a  unique  username  and  password  combination,  and  are  associated 
with  Roles  and  Groups  by  a  many-to-many  relationship.  Users  are  associated  with 
Person  objects  by  a  many-to-one  relationship.  (A  User  is  related  to  one  Person  object 
but  a  Person  Object  may  belong  to  many  users.) 

•  Persons  consist  of  a  First  Name,  Last  Name,  Gender,  Ethnicity,  and  a  Date  of  Birth. 
Persons  are  associated  with  Users  via  a  one-to-many  relationship.  (A  Person  may 
belong  to  many  users  but  a  user  may  only  have  one  Person.) 

•  An  Address  Object  consists  of  a  Type,  Address  One,  Address  Two,  City,  State,  Zip, 
and  a  unique  system  assigned  integer  id.  Addresses  are  related  to  Persons  by  a  many- 
to-many  relationship. 

•  Application  objects  consist  of  a  unique  Name,  Username  Parameter,  Password 
Parameter,  and  Little  Language/script  field.  Applications  share  a  many-to-many 
relationship  with  Users  and  Roles.  Applications  share  a  many-to-one  relationship 
with  Application  Logins. 

•  Application  Logins  consist  of  an  integer  id  assigned  by  the  system,  a  Username,  and  a 
Password.  Application  Logins  share  a  many-to-one  relationship  with  Users. 
Applications  Logins  have  a  one-to-many  relationship  with  Applications. 
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Figure  16:  The  GTMS  Security  Data  Diagram 


Applications  configured  to  work  with  the  GTMS  system  have  access  controlled  by  the  security 
policy.  Administrative  users  have  the  option  to  set  roles  associated  with  the  application. 

To  control  access  to  Applications,  an  administrative  user  is  able  to  assign  roles  to  the  application. 
If  a  user  attempts  to  access  an  application  or  data  related  to  the  application  assigned  to  a  Role  or 
Group,  the  user  must  also  be  assigned  the  appropriate  role  or  group  in  the  administrative 
interface. 

Roles  and  groups  are  appropriately  named  to  reflect  the  access  levels  that  possessing  the  role 
provides.  For  instance,  if  a  user  is  a  system  administrator,  he  or  she  should  have  the 
administrative  role.  The  current  hierarchy  contains  only  the  Basic  and  Administrator  roles.  The 
Basic  Role  allows  access  to  the  system,  system  pages,  and  objects  with  Basic  role.  The 
Administrator  role  will  allow  access  to  everything  in  the  system. 

Role  management  can  accommodate  new  roles  specifically  created  for  an  application.  For 
example,  an  administrator  can  add  a  new  application  called  GT  Nexus.  To  govern  the  user 
access  to  this  object,  the  administrator  can  create  a  new  role,  for  example,  called  "GT  Nexus 
Access"  and  assign  the  role  to  the  GT  Nexus  application.  No  user  without  the  GT  Nexus  Access 
or  Administrator  role  will  see  the  GT  Nexus  application. 

16.4  Transaction  Logging 

As  previously  stated,  upon  attempted  entry  to  the  GTMS  system,  subjects  are  challenged  for  a 
username  and  password  combination.  This  activity  occurs  before  access  to  any  other  part  of  the 
system  is  allowed.  Logs  are  accessible  via  a  user  interface  in  the  administrative  portion  of  the 
system  and  via  text  log  files  for  the  application  server.  The  logs  are  then  checked  to  determine 
who  or  what  changed  the  data  on  the  system. 
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Figure  17  System  Logging  Diagram 


GTMS  Administrative  users  will  be  able  to  set  the  role  level  which  users  must  have  in  order  to 
access  the  logged  activity.  Logs  will  not  be  altered  by  the  system  users  no  matter  what  role  the 
user  is  associated  with,  which  insures  log  integrity. 
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SECTION  D.  DOLE  EXPERIMENT 


17  1st  EXPERIMENT  -  DOLE 

The  first  experimentation  campaign  partner  is  Dole  Corporate  Package  Foods  (DPF)  division. 
Founded  in  Hawaii  in  1851,  Dole  Foods  is  the  world’s  largest  producer  of  high  quality  fresh  fruit 
and  fresh  vegetables.  Dole’s  geographical  reach  extends  to  more  than  90  countries,  with  a  line  of 
over  200  products.  Figure  18:  Dole  Shipping  Flow  demonstrates  shipment  flows  for  Dole  Foods 
moving  from  the  Philippines  to  the  Ports  of  Los  Angeles  and  Long  Beach  onto  further 
destinations  in  the  US. 


(MAERSK,  NYK,  CMA) 


Joliet,  IL 


Rail 

Terminal 


Figure  18:  Dole  Shipping  Flow 

The  purpose  of  the  Dole  Foods  proof  of  concept  is  to  demonstrate  capabilities  that  will  help  Dole 
improve  distribution  Center  (DC)  service  levels,  reduce  inventory,  reduce  costs,  and  increase 
productivity.  A  subset  of  Dole  Food’s  supply  chain  and  SKUs  are  included  in  this  project.  The 
product  line  SKUs/items  include  canned  pineapple  juice  and  the  supply  chain  network  scope  are 
shown  below. 

There  are  two  primary  multi-modal  logistics  flows  represented  in  the  project. 

•  Ocean  to  the  Port  of  Los  Angeles/Long  Beach  (LA/LB)  and  then  ground  to  the  Buena  Park 
DC. 

•  Ocean  to  the  Port  of  LA/LB  and  then  rail  to  the  Fort  Worth  and  Joliet  rail  ramps  (Joliet 
freight  has  since  been  moved  via  Hapag,  and  will  not  be  included  in  the  IOC.) 
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18  EXPERIMENT  OBJECTIVES 

Through  the  initial  requirements  spiral,  a  high-level  Value  Stream  Analysis  was  performed  on 
DPF’s  current  state  regional  distribution  network  for  DPF  commodities  from  Dolefil.  DPF 
imports  large  quantities  of  these  products  from  the  Philippines  through  the  Port  of  Los  Angeles 
(POLA)  or  the  Port  of  Long  Beach  (POLB).  The  products  then  move  either  to  their  inland 
distribution  center  in  Buena  Park,  California  or  continue  eastward  by  rail  to  its  distribution 
centers  in  Dallas  Ft.  Worth,  Texas  and  Joliet,  Illinois.  The  primary  objectives  of  the  Value 
Stream  Analysis  (VS A)  was  to  facilitate  the  identification  of  capability  gaps,  to  prioritize 
experimentation  areas,  and  to  improve  distribution  process  flows  and  overall  inventory  control. 

As  is  typical  in  this  industry,  the  VS  A  documented  numerous  manual  processes  and  various 
systems  used  to  support  shipment  movement  through  the  distribution  network.  For  example, 

DPF  manually  accesses  multiple  carrier  web  sites  to  check  shipment  status  in  order  to  maintain 
and  distribute  spreadsheets  to  track  containers.  The  expediting  of  the  urgent  containers,  also  a 
highly  manual  process,  includes  several  dynamic  factors  which  may  impact  the  overall 
scheduling  of  inbound  shipment  to  the  Distribution  Center  (DC).  These  factors  include  the 
amount  of  free  time  allowed  at  the  port,  carrier  transit  times,  demurrage  fees,  port  fees, 
operational  schedules,  and  the  physical  capacity  at  the  ocean  port,  dray  carrier,  and  distribution 
center.  The  tracking  of  container  status  is  extremely  inefficient  as  the  user  must  constantly  check 
the  websites  until  the  container  is  available  for  pick-up.  The  result  is  that  the  DPF  supply  chain 
can  be  slow  to  react  to  changes  in-demand  due  to  reliance  on  disparate  systems  and  manual 
processes  to  manage  supply  chain  and  inventory  systems.  This  lack  of  “real  time”  visibility  of 
shipments  and  potential  execution  failures  result  in  service  level  impacts  and  increased  inventory 
buffers. 

To  assist  in  the  transformation  of  the  DPF  supply  chain  into  a  competitive  advantage  by 
influencing  the  supply  chain  and  not  reacting  to  it,  three  (3)  main  components  for  an  agile 
distribution  network  were  identified: 

•  Early  sensing  of  potential  problem  areas  in  the  distribution  network  can  lead  to  a 
more  timely  response  and  resolution. 

•  Near-term  and  future  objectives  will  be  dependent  on  timely,  complete,  and  accurate 
data. 

•  The  high  number  of  transactions  across  the  distribution  network  can  only  be  managed 
effectively  by  exception. 

After  verification  with  DPF  and  their  supply  chain  partners,  five  (5)  key  capabilities  were 
defined  as  the  initial  features  for  GTMS  IOC  which  will  support  container  shipment 
management: 

•  End-to-End  Shipment  Tracking  and  Visibility 

•  Integrated  Global  Transportation  Management  (GTM) 

•  Automated  Container  Pick-up  Prioritization  and  Scheduling 

•  Exception  Based  Management 

•  Extended  SCM  Reporting 
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As  the  Dole  Foods  experimentation  VS  A  targeted  specific  DPF  product  lines  of  pineapple 
products,  the  IOC  will  focus  on  a  subset  of  transportation  carriers  and  lanes  which  provide 
service  to  DPF.  The  transportation  carriers  and  lanes  defined  below  will  assist  with  the 
validation  of  the  IOC. 

•  Port  of  General  Santos,  Philippines  to  Port  of  Los  Angeles/Long  Beach,  U.S.A. 

Ocean  carriers  selected  for  experimentation  are  Maersk,  NYK,  and  CMA. 

•  Port  of  Los  Angeles/Long  Beach  to  Distribution  Center  in  Buena  Park,  CA 
Dray  carrier  selected  for  experimentation  is  JAC  Trucking. 

•  Port  of  Los  Angeles/Long  Beach  to  Rail  Intermodal  Ramps  in  Ft.  Worth,  TX  and 
Joliet,  IL 

Rail  carriers  selected  experimentation  are  BNSF  and  UP. 

Keys  to  the  success  of  the  SM21  IOC  will  be: 

•  Cooperation  among  the  technology  solution  vendors  and  supply  chain  partners. 

•  Full  understanding  of  each  partner’s  capabilities  and  limitations. 

•  Collection  of  the  most  accurate  and  timely  data  available  in  the  industry. 

•  Availability  and  responsiveness  of  the  supply  chain  partners  for  detailed  requirements 
gathering  and  experimentation  participation. 

19  SHIPMENT  DATA  FLOW 

Figure  19:  Dole  Data  Flow  shows  the  data  flow  that  will  be  used  for  this  experiment. 

As  described  in  the  previous  sections,  the  GTMS  will  collect  all  shipment  details,  in-transit 
events,  and  inventory  balance  across  DPF’s  supply  chain  partners  for  the  IOC.  These  incoming 
shipment  messages  will  be  processed  and  stored  into  a  centralized  semantic  database.  Based 
upon  the  information  consumed,  business  processing  logic  will  be  applied,  which  will  generate 
the  appropriate  normalized  data  feeds  from  the  GTMS  to  One  Network 

The  following  strategic  technology  partnerships  are  being  incorporated  into  the  GTMS  IOC: 

•  GT  Nexus  -  SaaS  -  Ocean  Carrier  shipment  In-Transit  Visibility. 

•  Transentric  -  SaaS-  Rail  Carrier  Shipment  In-Transit  Visibility. 

•  One  Network  Enterprises  -  SaaS  -  Distribution  &  Transportation  Management 
Solution. 


19.1  GT  Nexus 

In  this  first  iteration  of  services  implementation,  GT  Nexus  will  provide  the  GTMS  ocean 
shipment  visibility  for  the  Dole  Experimentation  Campaign.  GT  Nexus  is  an  established  on- 
demand  ocean  visibility  solution  that  has  established  connectivity  and  relationships  with  the  top 
twenty  (20)  ocean  carriers  and  exchanges  over  500,000  messages  a  day. 

This  solution  will  include  collecting  and  standardizing  near-real-time 
•  EDIX12  315  -  Ocean  Carrier  Shipment  Status 
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o  Full  in-gate  at  Ocean  Terminal 
o  On-board  vessel  at  Port  of  Origin 
o  Vessel  departed  Port  of  Origin 
o  Vessel  estimated  Time  of  Arrival  (ETA) 
o  Customs  Released 
o  Vessel  arrived  Port  of  Discharge 
o  Container  Available  Notice 
o  Full  out-gate  from  Ocean  Terminal 


ServiceCraft 

Fog  i  s  M  c  s 


I 


ASN-Advanced  Shipment  Notice  (CSV) 
EDI  943-Whse  Shipment  Advice 


EDI  846-Inventory  Inquiry 

EDI  944-Whse  Shipment  Receipt 

EDI  945-Whse  Shipping  Confirmation 


Distribution  Center  Inventory  (CSV) 
Shipment  Info  and  Events  (XML) 


G  T  NEXUS 


EDI  310-Ocean  Carrier  Invoice  (XML) 
EDI  31 5-Ocean  Shipment  Status  (XML) 


BARTHCO 


EDI  31 5-Ocean  Shipment  USCBP  Status 
(Maersk,  CMA  &  NYK) 


V 


Figure  19:  Dole  Data  Flow 


o  Full  container  delivery 
o  Empty  container  returned 

•  EDIX12  310  -  Ocean  Carrier  Freight  Receipt 

Initially,  GT  Nexus  will  synchronize  the  ocean  carrier  integrations  and  normalize  the  data  across 
the  selected  carriers  identified  for  the  IOC  (Maersk,  NYK  and  CMA).  Through  a  standard  XML 
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interface  process,  the  ocean  data  will  be  sent  to  the  GTMS  to  be  processed  and  loaded  into  the 
semantic  data  store.  The  following  is  a  short  list  of  expected  ocean  events  provided  by  the  315 
that  will  be  collected  across  the  IOC  ocean  carriers. 


{  Shipment  Detail  GB323Z23I 


Container 
Container  Type 
Booking  # 

B/L  instruction 
B/L 

Vessel/Voyage 


MWCU6220332 
40'  RE 
598903046 
N/A 

MAEU 598903046 
MAERSKALFIRK  0905 
MAERSK 

BROOKLYN  0905 


Shipper 
Carrier 
Consignee 
Notify 
Also  Notify 


DOLE  THAILAND  LTD 
Maersk  Line 
Dole  Foods  Co. 

BARTHCO  INC-LOS  ANGELES 

MADISON  WAREHOUSE,  DOLE  PACKAGED  FOODS  INC 


Place  of  Receipt 
Port  of  Load 
Port  of  Discharge 
Place  of  Delivery 


Bangkok,  Thailand 
Laem  Chabang,  Thailand 
Los  Angeles,  CA,  United  States 
Fort  Worth,  TX,  United  States 


03/28/2009  (Actual) 
03/30/2009  (Actual) 
04/18/2009  (Actual) 
04/24/2009  (Actual) 


Other  Reference  091363 

280769 
MSK 

V0781553149 

V0781553149 

V0781553149 

V0781553149 

V0781553149 


Event 

Vessel 

Voyage 

Location 

Empty  Container  Returned 

MAERSKALFIRK 

0905 

Fort  Worth 
(Place  of  Delivery) 

Fuji  Container  Delivery 

MAERSK  ALFIRK 

0905 

Fort  Worth 
(Place  of  Delivery) 

Full  Out  Gate  at  Inland  or  Interim  Point  [Destination': 

MAERSK  BROOKLYN 

0905 

Fort  Worth 
(Place  of  Delivery) 

Full  In  Gate  at  Inland  or  Interim  Point  (Destination) 

MAERSK  BROOKLYN 

0905 

Fort  Worth 
(Place  of  Delivery) 

Off  Rail  (Destination) 

MAERSK  ALFIRK 

0905 

Fort  Worth 
(Place  of  Delivery) 

Carrier  Released 

MAERSKALFIRK 

0905 

On  Rail  (Destination! 

MAERSKALFIRK 

0905 

(Port  of  Discharge) 

Full  Container  Discharged  at  Port  of  Discharge 

MAERSKALFIRK 

0905 

Los  Angeles 
(Port  of  Discharge) 

Vessel  Estimated  Time  of  Arrival 

0905 

L.S  Angeles 

Vessel  Arrived  at  Port  of  Discharge 

MAERSKALFIRK 

0905 

(Port  of  Discharge) 

Vessel  Departed  from  Transship  Point 

MAERSKALFIRK 

0905 

Hong  Kong 

Full  Container  Loaded  forTransshipment 

MAERSKALFIRK 

0905 

Hong  Kong 

Full  Container  Discharged  forTransshioment  MAERSK  BROOKLYN  0905  Hong  Kong 

Vessel  Arrived  at  Transship  Point  MAERSK  BROOKLYN  0905  Hong  Kong 

B/L  Processed  bv  Carrier  MAERSK  BROOKLYN  0905 


Vessel  Estimated  Time  of  Departure  0905  Laem  Chabang 


Vessel  Departed  from  Port  of  Loading  MAERSK  BROOKLYN  0905  Laem  Chabang 

(Port  of  Load) 

On-Board  Vessel  at  Port  of  Loading  MAERSK  BROOKLYN  0905  Laem  Chabang 

(Port  of  Load) 

Full  In  Gate  at  Ocean  Terminal  (CV  or  Portl  MAERSK  BROOKLYN  0905  Laem  Chabang 

(Port  of  Load) 


Help  ? 


Report  a  Data  Quality  Issue 


Date  Time 


04/27/2009  12:00  PM 

CST 

04/27/2009  08:06  AM 

CSX 

04/27/2009  08:01AM 

CSI 


04/22/2009  02:52  PM 

CST 

04/22/2009  10:14  AM 

_ CSJ 

04/22/2009  02:34  AM 

_  ESI 

04/20/2009  01:55  PM 

PST 


04/18/2009  03:57  PM 

_  ESI 

04/17/2009  06:00  PM 

_ ESI _ 

04/17/2009  04:36  PM 

PST 

04/06/2009  07:30  AM 

Asia/Hong  Kong 

04/06/2009  01:56  AM 

Asia/Hong  Kong 

04/04/2009  09:21AM 

Asia/Hong  Kong 

04/03/2009  09:24  PM 

Asia/Hong  Kong 

03/31/2009  09:57  PM 

ESI 

03/31/2009  11:00  AM 

Asia/Bangkok 

03/31/2009  06:20  AM 

Asia/Bangkok 

03/30/2009  10:08  PM 

Asia, Bangkok 

03/28/2009  09:58  PM 

Asia/Banqkok 


If  a  specific  location  is  not  mapped  to  a  time  zone  in  the  application,  the  governing  country  time  zone  is  used  and  this  may  result  in  a  difference  of  a  few  hours.  If  time  is  not  provided  to  the  application  by  the  carrier, 
the  default  setting  is  12  Noon  UTC. 


Add  Event  | 


Figure  20:  The  GT  Nexus  Shipment  Screen 


19.2  Transentric 

As  defined  in  the  IOC  transportation  lanes,  a  portion  of  the  shipments  will  move  by  rail  once  it 
arrives  at  the  POLA.  Transentric’s  Rail  Visibility  Platform  was  ranked  among  the  highest  for 
rail  visibility  services,  and  selected  as  the  second  visibility  product  to  be  integrated  into  the 
GTMS.  Transentric  is  an  established  on-demand  visibility  solution  in  the  Rail  Industry  that  has 
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connectivity  to  all  Class  I  Railroads  in  North  America,  and  exchanges  over  2.5  million  messages 
a  day. 

Transentric  will  provide  the  GTMS  rail  shipment  visibility  for  the  Dole  Experimentation 
Campaign.  This  will  include  collecting  and  standardizing  near-real-time  Rail  Carrier  Car 
Location  Messages,  (CLMs),  and  Rail  Carrier  Waybill  Interchange,  EDIX12  417,  data  for  all  of 
Dole  Foods’  rail  shipments  into  a  unified  platform.  Initially,  Transentric  will  synchronize  the 
rail  carrier  integrations,  normalize  the  data  across  the  selected  carriers  identified  for  the  IOC  (UP 
and  BNSF),  and  provide  dynamic  in-transit  ETAs.  The  CLMs  will  be  provided  by  the  IOC  rail 
carriers  in  an  AAR/NITL  Format  G,  which  includes  the  railcar  initial  and  number  and  the 
location  represented  as  a  SPLC  (Standard  Point  Location  Code).  The  SPLC  is  designed  to 
provide  each  point  originating  freight  and  each  point  receiving  freight  in  North  America  with  a 
unique  code  number.  The  code  number  is  constructed  to  identify  the  point  with  its  geographic 
location,  and  is  maintained  by  National  Motor  Freight  Traffic  Association  (NMFTA). 

Transentric  will  also  provide  dynamic  rail  in-transit  ETAs  providing  up  to  date  visibility  for 
“when”  the  shipment  will  arrive.  Through  a  standard  XML  interface  process,  the  rail  data  will 
be  sent  to  the  GTMS  to  be  consumed  and  loaded  into  the  semantic  data  store.  The  following  is  a 
short  list  of  expected  rail  events  provided  by  the  CLM  that  will  be  collected  across  the  IOC  rail 
carriers. 

•  Waybill  Processed 

•  Loaded  on  Flatcar 

•  Departure  from  Location 

•  Arrival  at  Destination 

•  Unloaded  from  Flatcar 

•  Constructively  Placed  (Container  Available  Notice) 

•  Ramp  Departure  (Full  out-gate  from  Intermodal  Ramp) 


Shipment  ID:  MWCU622033 


Rpt  Origin: 

Start  Date: 

Total  Days  in  Std: 
Detention  Days: 
Current  ETA: 

Fleet  1: 

Break  Event: 
Comment: 


LAHARAPMT  CA 
04/17/2009  10:36 


04/22/2009  10:31 
UE: 


Rpt  Destination: 
End  Date: 

Total  Transit  Days: 


ALLIANCE  TX 
04/22/2009  10:31 


Original  ETA: 
Fleet  2: 
Location: 


04/22/2009  05:00 


D  Additional  Comments 

|>  Billing  Details 
L/E: 

UPT  Car  Kind: 

Fleet  1 : 

Weight: 

Bill  of  Lading: 
Delivery  Date: 
Shipper: 

Origin: 

Care  of: 

Route: 

Commodity: 

Content: 

Customer  Area  1: 
Customer  Area  3: 


00048325 

LGB090408292 

MAERSK  INC 
LAHARAPMT  CA 


Assign  Code: 
AAR  Car  Kind: 
Fleet  2: 

Pro  Number: 

Consignee: 

Destination: 


BNSF 

2,860  CASES  UPC.  NO.  38900-03008  DOLE  MIXED 


STCC  Code: 

Customer  Area  2: 
Customer  Area  4: 


MAERSK INC 
ALLIANCE  TX 


4611110 


30 


WAYBILL 

LAHARAPMT  CA 

WBMSG 

BNSF 

04/17/2009  10:36 

LOAD  ON  FLATCAR  (CONTAINTER)  - 

LAHARAPMT  CA 

BNSF 

04/18/2009  21:41 

LOAD  ON  FLATCAR  (CONTAINTER)  - 

LOSANGHAR  CA 

BNSF 

04/18/2009  21:41 

DEPARTURE 

LAHARAPMT  CA 

QLC118 

BNSF 

04/19/2009  07:48 

DEPARTURE 

BARSTOW  CA 

QLC118 

BNSF 

04/19/2009  13:48 

DEPARTURE 

NEEDLES  CA 

QLC118 

BNSF 

04/19/2009  17:51 

DEPARTURE 

WINSLOW  A Z 

QLC118 

BNSF 

04/20/2009  02:55 

DEPARTURE 

BELEN  NM 

QLC118 

BNSF 

04/20/2009  09:33 

TRAIN  ARRIVAL 

CLOVIS  NM 

QLHACL 

BNSF 

04/20/2009  16:20 

DEPARTURE 

CLOVIS  NM 

QSA119 

BNSF 

04/21/2009  14:27 

DEPARTURE 

CHILDRESS  TX 

QSA1 19 

BNSF 

04/21/2009  22:22 

DESTINATION  ARRIVAL 

ALLIANCE  TX 

QSA119 

BNSF 

04/22/2009  03:55 
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Figure  21:  GTMS  -Transentric  Shipment  Screen 


19.3  Barthco 

Besides  collecting  the  standard  shipment  events  from  the  IOC  carriers,  the  GTMS  will  consume 
U.S.  Customs  &  Border  Protection  (CBP)  status  data  provided  by  Barthco.  Barthco,  which  acts 
as  DPF’s  Customs  Broker,  will  transmit  the  data  received  from  CBP  Automated  Broker  Interface 
(ABI)  in  an  Ocean  Carrier  Shipment  Status,  EDIX12  315  format.  This  data  feed  will  provide 
additional  visibility  into  CBP,  FDA  (Food  and  Drug  Administration)  and  USDA  (United  States 
Department  of  Agriculture)  shipment  holds. 

19.4  ONE  Network  Enterprises 

The  next  technology  component  provides  key  Transportation  Management  System  (TMS) 
planning  and  execution  capabilities  that  will  leverage  the  consolidated  in-transit  shipment  data 
collected  and  normalized  by  the  GTMS  in  a  standard  XML  interface.  Using  the  same  evaluation 
process,  ONE  Network  (ONE)  was  considered  to  have  one  of  the  more  advanced  technology 
strategies  among  the  vendors,  and  was  selected  to  provide  the  base  set  of  TMS  services  for  the 
IOC.  ONE  provides  a  flexible  Business  Process  Platform  (BPP)  which  enables  the  ability  to 
rapidly  compose  new  business  processes  and  expand  the  core  TMS  feature-set  to  adapt  to  the 
challenges  facing  dual-use  distribution  networks.  ONE  currently  has  over  3,200  trading  partners 
on  existing  commercial  networks,  and  manages  over  $1B  in  annual  trade  under  management. 

ONE  TMS  components  include: 


Demand  Driven  Distribution  Network  Optimization  &  Planning 

•  Demand  Management  and  Continuous  Incremental  Re-planning 

•  Multi-Enterprise  Inventory  Management 

•  Enterprise-wide  Order,  Shipment,  Transaction  and  Capacity  Management 

•  Multi-Enterprise  Collaboration  and  Exception  Management 

Constraint  Based  Demand  Driven  Transportation  Management  &  Appointment  Scheduling 

•  Transportation  Planning,  Optimization  and  Execution 

•  Electronic  Load  Tendering 

•  Transportation  Visibility  and  Tracking 

•  Synchronized  Demand  Driven  Appointment  Scheduling 
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Sense  and  Respond  Framework 

•  Predictive  Issue  Identification  and  Proactive  Resolution 

ONE  will  provide  an  exception  driven  user  interface  for  transportation  planning  and  execution. 
This  solution  has  the  ability  to  sense  exceptions  in  real  time  and  the  appropriate  action  across  all 
parties  in  the  network.  This  platform  also  provides  a  dynamic  virtual  environment  that  enables 
predictive  supply  chain  performance  modeling  in  a  controlled  off-line  representation  of  the  real- 
world  network.  The  end  user  will  have  access  to  ONE  through  a  Single  Sign-On  (SSO)  process 
provided  by  the  GTMS.  SSO  provides  centralized  access  and  control  to  the  various  technology 
solutions  integrated  within  the  GTMS. 

Under  the  IOC,  the  GTMS  will  first  and  foremost  provide  global  container  visibility,  status 
information,  and  monitoring  across  the  multiple  carriers  and  modes.  Shipment  and  tracking 
events  will  be  collected  and  normalized  by  the  GTMS,  and  then  transmitted  to  ONE.  For 
example,  Dole  Foods  will  be  able  to  search  for  a  specific  container  and  see  that  it  is  in-transit 
from  the  Philippines  to  the  Port  of  LA.  Additionally,  alerts  will  be  provided  when  certain 
exception  based  rules  occur,  such  as  a  container  that  is  scheduled  for  pickup  at  the  Port  of  LA 
but  is  not  in  “Ready  for  Pickup”  status. 


Figure  22:  GTMS-One  Network  Shipment  Screen 
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The  second  IOC  capability  which  will  be  provided  by  ONE  is  container  prioritization  at  the  Port 
of  LA  for  containers  destined  to  the  Buena  Park  DC.  Since  demand  changes  have  occurred  since 
the  orders  were  released  from  Dole  Philippines,  the  container  prioritization  and  schedule  is 
created  to  address  Buena  Park  DC’s  needs  based  upon  several  factors  such  as  the  following: 

•  Inventory  priority  for  inbound  orders  for  the  Buena  Park  DC; 

•  Port  and  Carrier  Costs  (i.e.  detention  costs,  terminal  fees); 

•  DC  receiving  capacity. 

19.5  Service  Craft 

In  order  to  provide  inbound  container  prioritization  to  the  Buena  Park  DC,  the  GTM  will  collect 
inventory  transfer  and  balance  data  directly  from  Dole  Package  Foods  and  Service  Craft,  which 
manages  and  operates  the  Buena  Park  DC.  For  incoming  product  into  the  DC,  Dole  Foods 
provides  an  EDIX12  943,  Warehouse  Stock  Transfer  Shipment  Advice  to  Service  Craft.  The 
EDIX12  943  will  be  provided  roughly  5-7  days  prior  to  shipment  arrival  at  the  port  of  discharge. 
The  source  and  timeliness  of  the  data  is  driven  by  a  manual  process  between  DOLEFIL  (Dole 
Philippines)  and  DOLEUSA  which  supplies  shipment  information  to  Dole  Foods’  ERP 
(Enterprise  Resource  Planning)  system.  Upon  physical  receipt  of  the  shipment,  Service  Craft 
will  generate  an  EDIX12  944,  Warehouse  Stock  Transfer  Receipt  Advice.  A  similar  data 
exchange  happens  for  product  shipping  out  of  the  DC.  Dole  provides  an  EDIX12  940, 
Warehouse  Shipping  Order  to  Service  Craft,  which  will  generate  an  EDIX12  945,  Warehouse 
Shipping  Advice,  upon  physical  shipment  of  the  product.  Service  Craft  also  provides  Dole 
Foods  with  an  EDIX12  846,  Inventory  Inquiry,  to  provide  a  daily  inventory  balance.  These  data 
exchanges  will  be  consumed  by  SM21  then  transformed  into  the  appropriate  data  elements  for 
ONE.  ONE  will  use  this  inventory  data  to  automate  the  planning  and  execution  of  containers  out 
of  the  port  and  into  the  DPF  Distribution  Center  at  Buena  Park. 

For  extended  visibility  of  shipment  details,  typically  an  ASN  (Advanced  Shipment  Notice), 
EDIX12  856,  is  used  to  augment  the  carrier  waybill  (ocean  or  rail)  to  provide  line  item/order 
information  specific  to  each  container  shipment.  The  ASN  message  will  be  used  to  associate 
shipment  details  such  as  the  UPC  (Universal  Product  Code)  and  quantity  to  an  actual  container 
shipment.  However,  DPF’s  version  of  an  ASN  is  an  Excel  file  which  is  e-mailed  to  DOLEUSA 
from  DOLEFIL  on  a  weekly  basis.  The  Excel  file  will  be  manually  provided  to  SM21  roughly 
2-3  weeks  prior  to  shipment  arrival  at  the  port  of  discharge.  This  data  feed  will  provide  the  IOC 
visibility  down  to  the  line-item  level  for  ocean  shipments  inbound  to  the  DCs. 

20  DOLE  EDI  FLOW 

The  GTMS  System-of-Systems  Service  (SoS)  Service  Oriented  Architecture  (SOA)  is 
fundamentally  in  line  with  the  DISA  (Defense  Information  Systems  Agency)  commitment  to  the 
“ABC”  philosophy:  “Adopt-before-Buy,  Buy-before-Create.”  SM21  is  leveraging  existing  and 
evolving  logistics  and  transportation  technical  capabilities.  The  key  to  ABC  is  the  adaptation  of 
commercial  best  practices,  architectures,  and  standards. 

To  address  the  distribution  visibility  capability  gap,  SM21  program  technical  management  team 
evaluated  the  available  best-of-breed  products  and  services  to  support  the  experimentation  and 
the  development  of  the  GTMS  IOC.  These  common  visibility  platforms  augmented  with  DPF 
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distribution  supply  chain  partners  will  provide  the  required  processing  and  movement  data  that 
action  level  systems  and  resources  will  need  in  order  to  achieve  the  objectives  in  further  spirals 
and  experimentation  campaigns.  Figure  23  below  depicts  the  Systems  View  (SV)  of  the 
SM21  developed  GTMS  IOC  and  the  overall  Dole  Foods  EDI  flow.  The  following  sections  of 
this  document  will  explain  the  IOC  feature  capabilities  and  interfaces  of  the  GTMS. 

Product  evaluations  were  conducted  to  determine  the  initial  best-of-breed  global  visibility 
services  to  be  included  in  the  GTMS  Service  Oriented  Architecture  (SOA).  A  standardized 
evaluation  process  was  developed  to  assist  with  the  selection  of  the  top  rated  In-Transit  Visibility 
(ITV)  and  Transportation  Management  System  (TMS)  solutions  that  can  support  the  various 
modes  of  delivery.  Each  criterion  received  a  weight  factor  representing  the  overall  importance 
of  the  feature  within  the  GTMS  architecture.  The  evaluation  criteria  consisted  of  several 
categories  including  the  established  relationships  with  multiple  carriers  and  partners;  the  ability 
to  provide  accurate  and  reliable  shipment  data;  it  enables  the  customer  to  access  exception 
management  reports  and  notifications  of  existing  or  potential  issues  with  shipments;  the  key 
technology  components  of  the  system  and  adherence  to  open  standards;  the  platform  is  provided 
as  a  Software  as  a  Service  (SaaS)-based  offering;  and  the  ability  to  adapt  to  the  dual-use 
capability  objective. 


Figure  23:  Dole  EDI  Flow 
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After  applying  the  weighting,  a  rating  was  developed  for  each  criterion  based  upon  product 
demonstrations,  phone  conversations,  vendor  provided  documentation,  strategic  partnerships, 
customer  base,  product  and  market  vision,  pricing  model,  SM21  SOA  adaptability,  and  collective 
team  judgment.  Using  this  rating  system,  the  GT  Nexus  Ocean  Visibility  Platform  was  ranked 
among  the  highest  for  ocean  visibility  services,  and  selected  as  the  initial  visibility  product  to  be 
integrated  into  SM21. 
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Figure  24:  Activated  Parts  of  System 
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SECTION  E.  SYSTEM  FLOWS 

These  next  chapters  address  the  underlying  rules  that  drive  the  system  that  has  been  provided  for 
this  experiment.  It  should  be  remembered  that  the  focus  was  to  demonstrate  the  functionality  of 
combined  data  sources  to  provide  an  improved  Global  Trade  Management  System. 


21  PROPOSED  DATA  SOURCES  &  INFORMATION  FLOWS 

This  section  is  intended  to  summarize  the  previous  discussion  into  a  form  that  will  allow  the 
reader  to  proceed  to  the  near  term  design  of  the  system.  It  takes  each  player  and  graphically 
depicts  the  roles  they  play.  This  document  will  then  move  onto  the  basic  rules  for  managing  the 
events  of  the  system. 

The  following  summary  slides  provide  an  overview  of  the  shipment  flows  as  well  as  expected 
data  sources. 


Proposed  Data  Sources  and  Information  Flow  -  POC  Phase 
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Custom- 
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Shipment 
Advice 
EDI  943 


Shipping 
Order 
EDI  940 


Dole  Philippines  (DOLEFIL)  will  send 
out  an  Advance  Shipment  Notice  (ASN) 
to  Dole  USA  for  all  shipments  that  were 
booked  that  week.  Shipments  are 
typically  booked  approximately  2  weeks 
prior  to  sailing  and  the  ASN  file  is 
generated  on  a  weekly  basis  and  will 
have  the  shipment,  vessel,  voyage,  and 
container  content  details.  Upon  receipt 
of  the  ASN,  Dole  USA  will  send  a  copy 
to  SM21 . 


Once  the  ASN  is  loaded  into  Dole’s 
ERP  system,  EDI  940  and  943  files  are 
sent  to  the  different  warehouses  and  a 
copy  to  SM21 . 


Ocean 
Invoice 
EDI  310 


Once  the  booking  is  created, 
an  Ocean  Invoice  (EDI  310) 
will  be  generated  and  sent  to 
GT  Nexus.  The  file  will 
confirm  the  vessel  and 
voyage  info  and  identify 
transshipment  points. 

The  310  will  provide  the  ETA 
for  the  following  ocean 
shipment  milestones  and  EDI 
315  will  report  actual  dates 
and  time. 

•  Place  of  Receipt 

•  Place  of  Loading 

•  Port  of  Discharge 

•  Place  of  Delivery 


Ocean 

Status 


The  following  milestones  will  be 

tracked  for  each  shipment: 

•  Full  in-gate  at  Ocean 
Terminal 

•  On-board  vessel  at  Port  of 
Loading 

•  Vessel  departed  Port  of 
Loading 

•  Customs  Released 

•  Carrier  Released 

•  Vessel  arrived  Port  of 
Discharge 

•  Full  container  discharged  at 
Port  of  Discharge 

•  Full  out-gate  from  Ocean 
Terminal  (local  dray) 

•  On  Rail  (Destination) 

•  Off  Rail  (Destination) 

•  Full  out-gate  from  Inland 
Point  (Destination) 

•  Empty  container  returned 


US  Customs 
Notice 

EDI  31ji__ _ 

The  following  Customs, 
USDA  and  FDA  related 
milestones  will  be  tracked  for 
each  shipment  and  Barthco 
will  send  EDI  315s  for  each: 


Documents  Received 
Broker  submits  and  files 
entry  with  ABI 
FDA  Hold 
US  Customs  Hold 
USDA  Hold 

US  Customs  Clearance/ 
Release 

FDA  Clearance/  Release 
Container  Cleared/ 
Available  for  Pick-up 
Delivery  Order  Issued 


Figure  25:  Dole,  GTNexus  and  Barthco  Shipment  Data  Flow 
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EDI  Files  I  Milestones 


Proposed  Data  Sources  and  Information  Flow  -  POC  Phase  (cont'd.) 
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Shipping 
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The  Ocean  Carrier  will  send 
a  404  Bill  of  Lading  to  the 
Rail  Carrier  informing  them 
of  the  rail  shipment.  A  41 7 
rail  waybill  is  sent  to 
Transentricsoon  after  the 
vessel  arrives  at  the  port. 
The  41 7  file  will  contain  the 
following  info: 

•  Container  Number 

•  Rail  Carrier 

•  Bill  of  Lading  No. 

•  Destination  ETA 

•  Train 

•  STCC  (product) 

•  Weight 

•  Route  (interchange 
points) 


The  following  milestones  will  be 
tracked  once  the  trip  is  initiated. 


Waybill  Issued 
Load  on  Rail  Car 
Departure 

Reads  on  Intermediate 
Points 
Train  Arrival 
Unload  on  Rail  Car 
Constructive  Placement 
(Container  Available) 


Each  sighting  event  message 
will  include  an  updated  ETA  to 
rail  destination. 


Once  the  warehouse 
receives  and 
unloads  the 
container,  their 
Warehouse 
Management 
System  (WMS) 
generates  an  EDI 
944  and  sends  it  out 
to  Dole  to  update  its 
ERP  system.  A 
duplicate  copy  of  the 
EDI  file  will  be  sent 
to  SM21 . 


As  customer  orders 
are  fulfilled,  the 
warehouse  WMS 
generates  an  EDI 
945  to  notify  Dole 
that  the  order  is 
processed  and 
inventory  is  reduced 
accordingly.  A 
duplicate  copy  of  the 
EDI  file  will  be  sent 
to  SM21 

Note:  The  EDI  944 
and  945  files  are 
received  by  SM21  as 
soon  as  the 
warehouse  clerk 
enters  the 
transaction  in  the 
WMS  system. 


Daily  inventory 
status  is  sent  to  Dole 
to  update  their  ERP 
system.  SM21  will 
receive  a  duplicate 
copy  to  adjust  the 
inventory  count 
accordingly. 


Figure  26:  Transentric  and  ServiceCraft  Shipment  Data  Flow 
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This  next  graphic  provides  the  information  flow  that  occurs  around  the  shipment.  Please  pay 
attention  to  the  legend  that  explains  where  the  shipment  flow  exists.  The  Dole  Foods  box 
basically  initiates  the  action.  The  flow  follows  the  “slides”  in  the  earlier  sections.  You  can  then 
see  where  the  players  obtain  their  information  and  how  that  information  flows  through  the 
process. 


Figure  27:  Shipment,  Process  &  Information  Flows 
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How  the  Different  Data  Sources  Will  Be  Used 


The  EDI  files  will  be  processed  and  provide  what  is  need  for  shipment  tracking 
(from  ocean  carrier  to  dray)  and  prioritization  for  the  DC: 


x 


EDI  943/944  (DC  Inbound) 
EDI  940/945  (DC  Outbound) 
EDI  846  (Inventory) 


One  Network  Enterprises 


Inventory 


Shipment 

Details 


Shipment 

Events 


4 
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•  One-stop  shop  for 
shipment  tracking  (across 
carriers  and  modes) 

•  Automated  priority  and 
scheduling  lists  (for  dray) 

•  Automated  notification  for 
exceptions 

•  Provide  info  for  resource 
planning  and  optimization 


•  Reporting  and  analysis 
across  carriers  and 
modes 


Figure  28:  Data  Source  Functions 

While  the  EDI  944  (Shipment  Receipt)  is  shown  as  an  inventory  item  message,  it  also  represents 
the  final  message  indicating  the  completion  of  the  shipment. 

Assumptions 


•  Dole  will  send  the  Custom  ASN  file  via  email  every  Monday  morning. 

•  We  will  only  be  needing  EDI  files  from  Dole  for  ServiceCraft  warehouse 
(SER)  shipments.  Tracking  of  data  to  MCH  and  MFW  will  only  include  up 
to  the  rail. 

•  Transentric  messages  will  only  apply  for  Madison  warehouses  in  Texas 
and  Chicago  (MFW  and  MCH). 

•  Real-time  dray  tracking  for  JAC  will  not  be  includes  during  the  POC. 

JAC  dispatcher  will  use  the  system  to  confirm  scheduling  of  container 
pick-up  at  the  port. 


Figure  29:  Assumptions 
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Events  that  Trigger  State  Transitions  for 
Ocean  Movements 


Documents  Received 
Broker  Files  with  ABI 


a  JL 


Customs  Hold  &  Release 


USDA  Hold  &  Release 
FDA  Hold  &  Release 
Other  Hold  &  Release 
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Vessel  Departed  T/S  Port 
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Figure  30:  Ocean  Movement  State  Transition  Triggers 


Events  that  Trigger  State  Transitions  for  Rail 

Movements 
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Figure  31:  Rail  Movement  State  Transition  Triggers 
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Events  that  Trigger  State  Transitions  for 
Ground  Movements  to  ServiceCraft 


Customs  Hold  &  Release 
USDA  Hold  &  Release 
FDA  Hold  &  Release 
Other  Hold  &  Release 


DO  Issued 

Discharge 


Empty  Container  Returned 

I 


I 


Awaiting  Confirmed 

Pick 

In  Transit 

Delivered 

# 

Ready 

•  Dole  runs  Shipment  Prioritization  for  Awaiting  shipments. 

Legend: 

•  Error  log  is  reviewed  to  find  containers  which  have  not 
been  Prioritized. 

EDI/Everrt 

CD 

*  Dole  Tenders  shi pm ents  to  provide  vis ibility  to  JAC. 

Shipment  State 

Figure  32:  Ground  Movement  State  Transition  Triggers 


The  next  two  diagrams  show  how  this  flow  process  looks  going  end-to-end  from  booking  to 
receipt  for  each  of  the  two  destinations  being  used. 
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End  to  End  -  Shipments  to  ServiceCraft 

Customs  Hold  &  Release 
USDA  Hold  &  Release 
FDA  Hold  &  Release 
Other  Hold  &  Release 


Confirmed  Pick  In  Transit  Delivered 

Ready 


•  Dole  runs  Shipment  Prioritization  for  Awaiting  shipments. 

•  Error  log  is  reviewed  to  find  containers  which  have  not 
been  Prioritized. 

•  Dole  Tenders  shipments  to  provide  visibility  to  JAC. 


Legend: 

Ocean  State 

Ground  State 

— 

Figure  33:  End-to-End  ServiceCraft 


End  to  End  -  Shipments  to  Fort  Worth 
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Figure  34:  End-to-End  Fort  Worth 
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22  PROGRAM  FLOW 

Figure  35:  IDEFO  Model  -  JDDSP-OS  IOC  Data  Processing  provides  a  higher  level  approach  to 
system  process  while  Figure  36:  Program  Flow  provides  more  detail  of  the  various  modules  used 
to  produce  the  process.  Files  (messages)  are  received  and  stored  in  individual  directories.  A 
Java  utility  polls  the  directories  to  see  if  there  are  any  new  items.  It  then  transfers  control  to  the 
appropriate  message  handler  for  processing.  The  message  handler  processes  the  information  and 
passes  the  information  to  the  type  of  transaction  to  be  generated  for  transmission  or  file  transfer 
to  ONE  Network. 
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Figure  35:  IDEFO  Model  -  JDDSP-OS  IOC  Data  Processing 
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Figure  36:  Program  Flow 


There  are  three  types  of  messages  prepared  for  ONE: 

•  Shipment  List  -  provides  contents  of  the  shipment. 

•  Shipment  Event  -  provides  a  status  of  the  shipment. 

•  Buffered  Upload  -  provides  inventory  available  as  well  as  potential  lost  sales  from  an 
identified  inventory  deficiency. 

22.1  Shipment  List  (Detail) 

As  the  shipment  moves  from  one  mode  of  transportation  to  another,  consolidation  or 
reorganization  of  the  shipment  can  occur.  As  a  result,  the  relevant  information  needs  to  be 
updated  as  the  shipment  goes  from  Advanced  Shipment  Notification  (ASN  as  seen  on  the  CTF 
file)  to  the  ocean  mode  (EDI  310  -  Ocean  Invoice)  to  the  rail  mode  (EDI  417  -  Rail  Waybill). 
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22.2  Shipment  Events 

Shipment  events  are  basically  a  translation  of  the  various  EDI  into  shipment  events.  The  charts 
below  provide  the  correlation.  Except  for  the  EDI  310,  which  causes  a  shipment  list  to  be 
generated  and  that  ONE  then  also  translate  into  an  event,  each  of  the  EDI  messages  is  analyzed 
and  then  causes  state  changes  (i.e.,  events)  to  be  communicated  to  ONE.  The  charts  below 
provide  the  translations  for  the  various  legs  of  a  shipment. 
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Figure  37:  Ground  &  Ocean  Message  Translation 
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Figure  38:  Rail  &  Ground  Message  Translation 

22.3  Buffered  Upload 

The  buffered  upload  provides  the  inventory  on  hand  as  well  as  the  net  open  orders  that  cannot  be 
serviced  by  the  inventory  on  hand  at  the  given  distribution  center  (DC). 

•  The  inventory  on  hand  is  provided  by  the  EDI  846  transaction. 

•  The  open  orders  are  the  total  of  the  EDI  940’s  (shipment  orders)  minus  the  total  of  EDI 
945 ’s  (Shipping  Confirmation). 

•  The  amount  of  this  overall  difference  is  compared  with  the  inventory  on  hand  and  the  net 
deficiency  is  reported  as  potential  lost  sales. 


23  DEPLOYMENT  MODEL 

Figure  39:  Deployment  Model  shows  the  general  deployment  model  for  the  application. 


Figure  39:  Deployment  Model 
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SECTION  F.  FUTURE  STATE 


24  DOLE  FUTURE  STATE 

The  SM21-Dole  experimentation  campaign  will  be  completed  with  a  demonstration  of  the 
GTMS  IOC.  However,  further  analysis  with  Dole  Foods  is  expected  to  continue  beyond  the 
bounds  of  the  GTMS  IOC  by  extending  further  into  the  distribution  supply  chain  and  spiraling 
into  the  next  deployment  iteration  based  on  a  defined  set  of  capability  improvements.  It  is 
envisioned  that  these  future  capabilities  will  either  be  developed  under  Level  6  Logistics  LLC, 
the  identified  JDDSP-OS  (Joint  Deployment  and  Distribution  Support  Platform-Operations 
System)  transition  organization,  or  transition  to  an  interim  entity  for  continued  development. 
Future  capabilities  will  most  likely  include: 

•  Enhanced  ocean  and  rail  shipment  visibility  by  way  of 

o  On-boarding  the  remaining  Dole  product  lines,  business  units,  transportation  carriers 
and  partners, 

o  Source  in-transit  events  from  the  terminal/port  to  augment  the  carrier  shipment  status, 
and 

o  Source  in-transit  events  directly  from  transportation  carriers  to  enhance  data 
redundancy  and  accuracy. 

•  Expand  end-to-end  inventory  visibility  by  starting  at  sales  order  then  ending  at  the  retailer’s 
shelf. 

•  Provide  drayage  tracking  and  Fleet  Management  capabilities  to  enhance  visibility  and 
management  of  shipments  moving  between  the  ocean  and  rail  terminals  to  the  DCs. 

•  Implement  Global  Trade  Compliance  Management  capabilities  to  assist  with  compliance  for 
all  areas  of  Customs  rules  and  regulations,  such  as  Importer  Security  Filing  (ISF)  “10+2”  and 
Customs-Trade  Partnership  Against  Terrorism  (C-TPAT),  including  Free  Trade  Agreements 
and  related  agencies  such  as  USDA  and  FDA. 


48 


SOURCE  SYSTEMS 


GLOBAL  TRANSPORTATION  MANAGEMENT  (GTM) 


DOLE  ERP 
(JD  Edwards) 


Customs  Broker 
(BARTHCO) 


MAERSK 


NYK 


CMA-CGM 


UP 


BNSF 


JAC  Trucking 


Distribution  Center 
(SERVICE  CRAFT) 


SOURCE  n... 
(Other  Data) 


System  SOA  Web  Portal  -  a  one  stop  shop  for 
Dole’s  GTM  needs 

Integrated  with  Dole  and  their  distribution 

partners  for  shipment  planning  and  execution 

across  the  distribution  network 

Provides  a  foundation  for  extended  supply  chain 

reporting  and  analysis 

Reliable  and  secure  information  access 


COMMERCIAL  SYSTEMS 


IN  TRANSIT  VISIBILITY 


TMS  FUNCTIONALITY 


GT NEXUS 

(Ocean  Shipment  Tracking) 


OCEAN  CARRIER 


TRANSENTRIC 
(Rail  Shipment  Tracking) 


PORT/TERMINAL 


PEOPLENET 

(Truck  Shipment  Tracking) 


RAIL  CARRIER 


MOTOR  CARRIER 


ONE  NETWORK 
(Transportation  Management) 


SYSTEMn... 

(OtherCapabilities) 


1 

DISTRIBUTION  CENTER 

i  BWB1 WSmmMMm; 


IMPORT/ EXPORT 
PROCESSING 


JDDSP  VALUE-ADD 
SERVICES 


TRANSPORTATION 

SOURCING 


INVENTORY  MGMT 


ORDER MGMT 


SHIPMENT 

PRIORITIZATION  & 
OPTIMIZATION 


CARRIER  CONTRACTS 
&  BOOKING 


DRAY  SCHEDULING 


EXCEPTION 

MANAGEMENT 


System  SOA  FRAMEWORK 

(Integration,  Security  and  User 
Mgmt  Services  Layer) 


OPEN  STANDARDS 

SEMANTIC  DATA 

SERVICES 

IDENTITY  ASSERTION 

DISA/FISMA  LEVEL 
SECURITY 

USER/APPMGMT 

SINGLE  SIGN-ON 
CAPABILITY 

JDDSP  WEB  PORTAL 


m 


Figure  40:  Dole  Future  State 
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SECTION  G.  APPENDICES 


APPENDIX  A  -  GLOSSARY 


Terminology 

Definition 

3PL 

Third  Party  Logistics 

AAR 

Association  of  American  Railroads 

ABI 

Automated  Broker  Interface 

ABox 

Assertion  component 

ASN 

Advance  Shipment  Notice 

B1 

Multi-level  secure  Definition  also  from  the  Orange  Book 

DoD 

Department  of  Defense 

DoDAF 

Department  of  Defense  Architectural  Framework 

DPF 

Dole  Package  Foods 

EDI 

Electronic  Data  Interchange 

EJB 

Enterprise  JavaBean 

ERP 

Enterprise  Resource  Planning 

ETA 

Estimated  Time  of  Arrival 

FDA 

Food  and  Drug  Administration 

FCS 

Future  Combat  System 

GTM 

Global  Transportation  Management 

HTTP 

Hypertext  Transfer  Protocol 

IOC 

Initial  Operating  Capability 

J2EE 

Java  Platform  Enterprise  Edition 

JAAS 

Java  Authentication  and  Authorization  Service 

JDDSP 

Joint  Deployment  and  Distribution  Support  Platform 

JDDSP-OS 

Joint  Deployment  and  Distribution  Support  Platform-Operations  System 

NITL 

National  Industrial  Transportation  League 

NMFTA 

National  Motor  Freight  Traffic  Association 

OWL 

Web  Ontology  Language 

PO 

Purchase  Order 

POLA 

Port  of  Los  Angles 

POLB 

Port  of  Long  Beach 

RDF 

Resource  Description  Framework 

RDFS 

Resource  Description  Framework  Schema 

REST 

Representational  State  Transfer 

RPC 

Remote  Procedure  Call 

SCLA 

Southern  California  Logistics  Airport 

SDM 

Systems  Development  Method 

SKU 

Stock  Keeping  Unit 

SM21 

Strategic  Mobility  21 

SOA 

Service  Oriented  Architecture 

SOAP 

Simple  Object  Access  Protocol 

SoS 

System  of  Systems 

SPLC 

Standard  Point  Location  Code 

SSL 

Secure  Sockets  Layer 

SV 

System  View 

51 


TBox 

Terminological  component 

TMS 

Transportation  Management  System 

UP 

Union  Pacific 

UPC 

Universal  Product  Code 

URI 

Uniform  Resource  Identifier 

URL 

Uniform  Resource  Locator 

USDA 

United  States  Department  of  Agriculture 

W3C 

World  Wide  Web  Consortium 

XML 

Extensible  Markup  Language 

XSD 

XML  Schema  Definition 
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APPENDIX  B  -  SECURITY  INTERFACE 


1  PROCESS  WITHIN  THE  GTMS 

To  access  the  GTMS  web  application  a  user  first  opens  a  web  browser  and  types  in  the  URL  of 
the  GTMS  domain.  This  request  is  immediately  routed  from  an  Apache  Web  Server  to  an  SSL 
connection  with  the  JBoss  Web  Application  Server.  JBoss  immediately  challenges  the  requester 
for  a  username  and  password  either  via  a  browser  dialogue  or  directly  through  the  browser. 

Administration 

Welcome! 

User  Login 

Username 
Password: 
f  Login  S| 


admin 


Figure  41:  Administrative  Login  Page 

JBoss  container  authentication  in  combination  with  JBoss,  the  web  module  and  the  underlying 
custom  JAAS  module  handles  the  authentication  steps.  The  data  is  available  via  a  web  service 
interface  which  adheres  to  both  popular  protocols  -  namely  REST  and  SOAP.  Configuration  of 
a  custom  JBoss  JAAS  Module  authenticates  the  user  based  on  the  information  in  the  database 
and  provides  the  opportunity  to  manipulate  the  GTMS  systems  connections  to  other  outside 
databases. 

The  JAAS  Module  discussed  above  checks  a  username  and  password  combination  against  stored 
user  information  in  a  database.  If  the  username  exists  in  the  database  and  the  password  entered 
by  the  user  matches,  a  user  object  is  built  and  the  roles  and  group  roles  associated  with  this  user 
object  are  assembled  and  stored  in  the  requested  context. 

If  a  login  attempt  fails  the  user  is  informed  on  the  login  page  where  they  can  attempt  to  login 
again. 
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Administration 


Usor  Login 
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admin 

f  Login 

Figure  42:  Denial  for  Failed  Login  Attempt 

The  use  of  JAAS  authentication  allows  easy  protection  for  access  to  individual  pages  on  the  site 
by  mapping  a  page  to  a  Role.  When  attempting  to  access  data  in  the  system,  the  assembled  roles 
are  checked  against  roles  assigned  to  the  accessed  object.  If  access  is  allowed  the  system  acts 
normally.  If  access  is  not  allowed  the  user  is  taken  to  an  error  page. 

An  authenticated  user  object  is  stored  on  the  session  as  a  principal.  This  principal  is  added  to  the 
session  during  user  authentication.  When  a  user  attempts  to  access  data  on  the  GTMS  system, 
the  session  identity  provides  access  to  roles  associated  with  the  authenticated  user,  and  these 
roles  are  checked  against  the  access  levels  related  to  system  objects  and  actions. 

2  TIMESTAMPS 

A  timestamp,  user,  activity,  and  activity  status  are  recorded  for  each  event.  When  a  new 
authentication  or  logout  event  occurs,  the  requester  specifics  are  logged  also.  For  deletion  and 
creation  of  events,  the  deleted  or  created  item’s  id  is  logged.  Logs  are  filtered  by  the  timestamp, 
user,  activity,  activity  status,  requester  information,  and  object  information.  Logs  are  associated 
with  users,  Applications,  and  Application  Logins  in  a  many-to-one  fashion. 

Administration 


Systom  Administration 
Logs 


Datc/TImo  ^ 

User 

Activity 

Acti  vity  Status 

2000-11-26  13:14:56.0 

admin 

Login 

Success 

Figure  43:  Logs  Page 
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A  set  of  automated  unit  and  functional  tests  thoroughly  subject  the  code  base  to  security  tests  to 
insure  the  application  handles  all  security  measures. 

GTMS  code  base  is  stored  in  a  Subversion  repository  that  is  accessible  via  a  secured  Apache 
server  or  by  accessing  the  box  using  an  authorized  user  on  the  server.  Subversions  architecture 
tags  each  change  to  the  code  base  and  provides  access  to  versions  of  code  previous  to  any 
changes.  Subversion  is  subject  to  an  independent  backup  to  insure  that  files  are  not  lost  due  to 
any  issues. 
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APPENDIX  C  -  SEMANTIC  WEB 

This  application  capability  was  added  for  additional  functionality  in  the  future.  It  was  an  add¬ 
on  and  not  originally  part  of  the  requested  capabilities  of  the  system. 

The  Semantic  Web  provides  an  automated  way  of  enhancing  the  collection  of  the  characteristics 
of  data  as  it  is  gathered  so  that  a  more  flexible  use  of  the  data  can  occur  at  a  later  stage.  This 
capability  is  achieved  by,  among  other  things,  setting  up  additional  relationships  with  the  data  as 
it  is  collected.  The  advantage  comes  at  a  later  time  when  the  data  needs  to  be  referenced  in  the 
context  of  its  intended  use,  rather  than  how  it  is  collected.  More  information  on  this  will  be 
provided  later. 

1  SEMANTIC  CAPABILITIES 


1.1  Semantically  Enabling  Data  Through  RDF,  RDFS  and  OWL 

Semantically  enabling  data  means  being  able  to  enhance  the  data  with  characteristics  when  the 
data  is  collected.  This  is  accomplished  using  RDF,  RDFS,  OWL  and  the  Vocabulary.  The  next 
diagrams  demonstrate  the  Semantic  relationship. 


Ontology 


I 

compliant  w*h 


Fact  Instances 


Figure  44:  Semantic  Web  Definitions 

The  terms  Abox  and  Tbox  are  used  to  describe  two  different  types  of  statements  in  ontologies. 
Tbox  statements  describe  a  system  in  terms  of  controlled  vocabularies,  for  example,  a  set  of 
classes  and  properties.  Abox  are  Tbox-compliant  statements  about  that  vocabulary.  Tbox 
statements  are  sometimes  associated  with  object-oriented  classes  and  Abox  statements  associated 
with  instances  of  those  classes.  Together  Abox  and  Tbox  statements  make  up  a  knowledge  base. 
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Figure  45:  Semantically  Enabling  Data 
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•  RDF  -  The  Resource  Description  Framework  (RDF)  is  the  W3C  standard  for  encoding 
knowledge.  RDF  provides  the  ability  to  express  any  fact  in  small,  structured  pieces.  It  is 
able  to  represent  knowledge  as  a  network  graph,  as  a  set  of  statements,  or  even  as  XML.  The 
design  of  RDF  is  suited  to  meshing  distributed  knowledge  sources  together.  Applications  use 
RDF  files  from  different  sources  to  derive  new  facts.  The  RDF  standard  enables  this  process 
by  providing  logical  descriptions  of  inferences  between  facts  and  instructions  on  how  to 
search  for  facts  in  other  RDF  documents.  These  facts  may  occur  in  the  local  document, 
external  document,  or  a  combination  of  both.  RDF  easily  learns  new  facts  by  being 
remarkably  flexible.  The  RDF  standard  not  only  links  documents  together  by  a  common 
vocabulary,  but  it  also  allows  any  document  to  use  any  vocabulary. 

•  RDFS  -  RDF  Schema  (RDFS)  provides  the  ability  to  type.  RDFS  determines  which  terms 
from  the  vocabulary  are  classes  and  which  are  properties. 

•  OWL  -  OWL  (Web  Ontology  Language)  is  the  top  layer  that  says  much  more  about  the 
vocabulary.  OWL  allows  the  system  to  place  more  restrictions,  and  with  these  restrictions,  a 
more  sophisticated  level  of  reasoning  on  the  data.  Additionally,  it  places  the  simple  terms 
from  the  vocabulary  into  an  object  model. 

As  a  result: 

•  RDF,  RDFS,  OWL  and  the  Vocabulary  are  layers  on  top  of  each  other. 

•  RDF  provides  a  format  to  express  a  fact,  in  the  form  of  Subject,  Predicate,  and  Object. 

•  The  vocabulary  places  terms  in  the  RDF  format. 

A  user  performs  a  text  search  against  all  available  data  sources,  including  those  available  through 
Web  Services.  Text  searches  search  for  matching  values  in  the  database.  For  example,  if  a  text 
search  is  for  “Smith,”  the  results  may  be  for  a  person  with  the  same  surname  or  for  a  street 
named  “Smith  Street.”  The  results  from  a  text  search  bring  back  the  URI  of  the  RDF  document. 

1.2  Semantic  Extensions 

As  the  types  of  data  sources  evolve,  the  GTMS  can  be  modified  to  accept  them.  Like  browsers, 
Wiki's  can  be  a  front-end  to  the  GTMS.  Wiki's  can  also  be  a  data  source.  Semantic  features  can 
be  enabled  through  the  utlizlation  of  Wiki  extensions. 

2  PERFORMANCE  MEASURES 

From  an  input  perspective,  the  processing  must  keep  pace,  meaning  messages  must  be  processed 
at  a  rate  higher  than  they  are  received.  The  initial  production  work  firmly  establishes  this  ability 
as  a  mitigated  risk.  Data  appears  at  a  rate  more  than  10  orders  of  magnitude  slower  than  the 
processing  of  the  EDI  files.  The  returning  of  data  must  occur  to  fill  a  web  screen  within  10 
seconds.  Current  processing  occurs  in  less  than  two  seconds. 

The  SM21  team  looks  to  take  the  RDF  and  build  a  consensus  across  carriers,  vendors  and 
shippers.  It  will  vet  and  take  feedback  from  real  shippers,  clients  and  carriers. 


57 


3  BLACKBOOK 

Blackbook,  which  is  multi-level  secure,  will  run  on  the  same  SOA  as  the  GTMS.  This  is  a 
standard  best  of  breed  approach.  Blackbook  is  a  semantic  web  processor  which  may  process  all 
incoming  data.  At  this  point,  incoming  data  is  stored  in  an  RDF  store.  Downstream  processing 
occurs  by  querying  data  from  the  RDF  store. 

The  purpose  of  Blackbook  is  to  provide  GTMS  users  with  an  easy-to-use  tool  to  access  valuable 
data.  The  tool  federates  queries  across  data  sources.  These  data  sources  are  databases  or 
applications  located  either  locally  or  remotely  on  the  network.  Blackbook’ s  architecture  fits  well 
within  the  GTMS  system.  Blackbook  is  a  J2EE  server-based  data  integration  framework  which 
relies  on  open  standards  to  promote  robustness  and  interoperability,  including  Jena,  June, 

Lucene,  JAAS,  D2RQ.  It  is  based  on  semantic  web  technologies  (I.e.,  RDF,  RDF  Schema, 

OWL,  SPARQL).  It  is  vocabulary  agnostic,  meaning  that  it  can  leverage  any  existing 
vocabulary  'for  free',  so  users  need  not  build  everything  from  scratch  (a  vocabulary  is  a  set  of 
consistently  used  and  carefully  defined  terms).  Vocabularies  construct  RDF  statements  that 
conform  to  the  RDF  format.  Blackbook  provides  a  default  web  application  interface,  and  uses 
SOAP  and  RESTful  interfaces.  It  also  provides  a  high  level  of  security  'baked  in'  (PL3  Appendix 
E  certified)  with  access  to  data  controlled  to  the  individual  user,  as  will  be  shown  below.  The 
data  processing  for  the  GTMS  may  be  One  Network,  Blackbook,  or  components  of  both. 

Blackbook  implements  the  layers  in  the  'semantic  stack'  that  are  now  most  technology  mature — 
i.e.,  up  to  the  ontology  level  using  OWL  —  and,  along  with  its  implementation  technologies  for 
indexing,  converting  data  to  RDF,  and  querying  data  and  work  flow,  it  allows  analysts  to  make 
logical  inferences  across  the  data  sources,  to  add  their  own  knowledge  and  share  that  knowledge 
with  others  using  the  system. 
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APPENDIX  D  -  SEMANTIC  WEB  TREATMENT  FOR  XML 
FORMATTED  EDI  MESSAGES  FOR  AIR,  OCEANIC,  RAIL,  AND 
TRUCK  TRANSPORT 

Basic  metadata  about  the  system  occurs  in  three  areas,  each  having  their  own  data  store: 

•  The  workspace/workflow  module  maintains  definitions  of  processing  for  users  and  groups  of 
users. 

•  The  security  module  maintains  access  controls. 

•  The  metadata  manager  modules  maintain  metadata  on  data  sources  themselves,  including 
EDI  data  sources. 

1  SEMANTIC  WEB  METHODOLOGY 

Step  1 

Describe  the  initial,  most  difficult  requirements  in  conversational,  informal  English.  Leverage 
any  existing  diagrams  or  formalisms. 

Step  2 

Decompose  the  problem  into  domain  components.  Pick  the  most  difficult  domain  as  a  starting 
point.  Add  in  any  “for  free”  completed  domains. 

Step  3 

Look  for  opportunities  of  abstraction  to  lessen  the  number  of  components. 

Step  4 

Research  existing  vocabularies  and  ontologies  in  similar  domains  to  use  in  composition. 

Step  5 

If  a  preexisting  vocabulary  does  not  exist,  model  it  yourself  creating  Tbox  entries. 

Step  6 

Take  an  instantiation  of  the  data  and  prove  it  can  work  on  paper. 

Step  7 

Use  a  semantic  web  implementation,  like  Jena,  to  build  a  Tbox  vocabulary. 

Step  8 

In  a  semantic  web  implementation,  instantiate  the  vocabulary  by  creating  instances  and  output 
the  instances  as  RDF/XML. 

Step  9 

Iterations  -  repeat  steps  1  through  8  until  complete. 

2  SHIPPING  VISIBILITY  CASE  STUDY 

Partners  will  send  SFTP  EDI  XML  event  messages  to  a  secured  server.  These  messages  will 
then  be  consumed  and  stored  in  a  semantic  data  store.  This  data  will  be  searched,  and  the 
messages  will  be  editable  via  a  web  based  user  interface  and  will  be  available  for  analysis  via 
dashboards  and  reports. 

The  EDI  XML  needs  to  be  transformed  into  logically  formatted  RDF  XML  that  takes  the 
messages  and  information  contained  within  into  account. 


61 


2.1  Step  1.  Describe  Requirements 

Goal:  Describe  the  initial,  most  difficult  requirements  in  conversational,  informal  English. 
Leverage  any  existing  diagrams  or  formalisms. 


Since  the  customer  wants  to  track  shipments,  the  problem  must  be  extruded  down  to  developing 
a  vocabulary  for  a  shipment. 


Figure  46  Shipment 


2.2  Step  2.  Decompose  Problem  into  Domain  Components 

Goal:  Decompose  the  problem  into  domain  components.  Pick  the  most  difficult  domain  as  a 
starting  point.  Figure  47  presents  the  problem  in  a  simpler  form  and  separates  it  into  its  domain 
components. 


Figure  47  Decomposed  Shipment 

2.3  Step  3.  Look  for  Opportunities  of  Abstraction 

Goal:  Look  for  opportunities  of  abstraction  to  lessen  the  number  of  components. 

The  number  of  components  pretty  much  fits  what  is  needed  to  display,  but  it  is  important  to  take 
a  closer  look  at  what  composes  each  domain  object. 

1.  Shipment  -  The  Shipment  will  have  a  Shipment  Id  literal  composed  of  the  Bill  of  Lading 
Id  and  Container  Number.  The  shipment  will  reference  the  Container  object,  Bill  of 
Lading  object.  Event  object,  Shipment  Leg  objects,  and  EDI  Message  objects. 


62 


2.  Shipment  Leg  -  The  Shipment  Leg  object  will  consist  of  a  literals  representing  location, 
an  estimated  time,  and  an  actual  time.  Shipment  legs  will  reference  a  Shipment  object 
and  an  EDI  Message  object. 

3.  Bill  of  Lading  -  The  bill  of  lading  will  have  a  bill  of  lading  number  literal.  Bill  of  ladings 
will  have  references  to  Container  objects,  EDI  Messages  objects,  and  Shipment  objects. 

4.  EDI  Message  -  The  EDI  Message  will  have  a  literal  for  the  EDI  Message,  Message  ID, 
and  Message  Set.  The  EDI  Message  will  have  references  to  Shipment  object,  Shipment 
Leg  object.  Bill  of  Lading  object.  Event  objects,  and  Container  objects. 

5.  Container  -  The  Container  object  will  have  literals  representing  the  Container  Number 
which  is  a  composite  of  a  prefix  and  number.  Container  Objects  will  have  references  to 
Shipment  objects,  Bill  of  Lading  objects,  and  EDI  Message  objects. 

6.  Event  -  The  Event  object  will  have  literals  for  Event  Id,  Location,  and  Time  Stamp. 
Event  objects  will  reference  Shipment  objects  and  EDI  Message  objects. 

2.4  Step  4.  Research  Existing  Vocabularies 

Goal:  Research  existing  vocabularies  and  ontologies  in  similar  domains  to  use  in  composition. 

The  existing  VCard:ADR  ontology  and  the  XSD  can  be  leveraged  for  date/time  to  cover  both 
location  and  date/time.  VCARD:ADR  provides  a  defined  locality  to  store  the  location 
information.  Latitude  and  longitude  will  be  stored  using  the  Geo  Point  Ontology  at 
http://www.w3.Org/2003/01/geo/wgs84_pos#.  A  custom  TBox  for  Shipment,  Shipment  Leg, 
Bill  of  Lading,  EDI  Message,  Container,  and  Event  will  have  to  be  created. 

2.5  Step  5.  Create  TBox  Entries 

Goal:  If  a  preexisting  vocabulary  does  not  exist,  model  it  yourself  creating  Tbox  entries. 

Shipment  TBox 

•  ID 

•  Container  TBox 

•  Shipment  Leg  TBox 

•  Bill  of  Lading  TBox 

•  Event  TBox 

•  EDI  Message  TBox 

Shipment  Leg  TBox 

•  ID 

•  Mode 

•  VCARD:  ADR 

•  Estimated  Arrival  Time  Stamp  (XSD) 

•  Actual  Arrival  Time  Stamp  (XSD) 

•  Estimated  Pickup  Time  Stamp  (XSD) 

a.  Actual  Pickup  Time  Stamp  (XSD) 

b.  Shipment  TBox 
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c.  EDI  Message  TBox 


Bill  of  Lading  TBox 

•  ID 

•  Payment 

•  Shipment  Id 

•  Container  TBox 

•  EDI  Message  TBox 

•  Shipment  TBox 

EDI  Message  TBox 

•  Message 

•  ID 

•  Message  Set 

-  Sent  Time  Stamp  (XSD) 

+  Container  TBox 

+  Shipment  Leg  TBox 
+  Bill  of  Lading  TBox 
+  Event  TBox 
+  Shipment  TBox 

Container  TBox 
-  ID 

•  Equipment  Type 

•  Quantity 

•  Package  Type 
+Shipment  Leg  TBox 
+Bill  of  Lading  TBox 
+EDI  Message  TBox 

Event  TBox 

-  ID 

+  VCARD:  ADR 

-  Time  Stamp  (XSD) 

-  event  code 

-  container  status 

-  location  function 

-  carrier  scac 

-  unique  character  data 
+  reference  to  Tbox 

2.6  Step  6.  Instantiate  Data 

An  example  EDI  310  XML  message  from  GT  Nexus  (See  Appendix  A.)  is  the  starting  point. 
From  the  XML  the  container  and  status  information  can  be  determined. 
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Figure  48  Container  KKLUANR800214.KKTU772062 


2.7  Step  7.  Implement  using  Semantic  Web  Technologies 

package  sm21.jena; 

import  com.hp.hpl.jena.ontology.DatatypeProperty; 
import  com.hp.hpl.jena.ontology.ObjectProperty; 
import  com.hp.hpl.jena.ontology.OntClass; 
import  com.hp.hpl.jena.ontology.OntModel; 
import  com.hp.hpl.jena.ontology.OntModelSpec; 
import  com.hp.hpl.jena.rdf.model.ModelFactory; 
import  com.hp.hpl.jena.rdf.model.Resource; 
import  com.hp.hpl .j ena. shared. PrefixMapping ; 

/** 

*  The  Shipping  Vocabulary  for  tracking  containers  and  their  related  information. 

* 

*  @  author  Rich  Brassell 

*  (Aversion  1.0 
*/ 

public  class  Shipping  { 

/*  General  Ontology  Information  Start  */ 

/**  <p>The  ontology  model  that  holds  the  vocabulary  terms</p>  */ 
private  static  OntModel  m_model  =  ModelFactory.createOntologyModel( 
OntModelSpec.OWL_MEM,  null ); 

/**  <p>The  namespace  of  sm21  the  vocabulary  as  a  string</p>  */ 
public  static  final  String  NS  =  "http://domains.intervise.eom/shipping/l.Q#"; 

/**  <p>The  namespace  of  the  vocabulary  as  a  resource</p>  */ 

public  static  final  Resource  NAMESPACE  =  m_model.createResource(  NS  ); 

/** 

*  <p>The  namespace  of  the  vocabulary  as  a  string</p> 

*  @see#NS 
*/ 
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public  static  String  getURI()  {  return  NS;  } 

/*  General  Ontology  Information  End  */ 

/*  Bill  of  Lading  Start  */ 

/** 

*  <p>This  class  represents  a  Bill  Of  Lading  containing  information  about 

*  containers  being  tracked.</p> 

*/ 

public  static  final  OntClass  BillOfLading  =  m_model.createClass(  NS  +  "BillOfLading" ); 

/*  Bill  of  Lading  End  */ 

/*  Container  Start  */ 

/**  <p>  Containers  are  represented  by  the  Container  object.</p>  */ 

public  static  final  OntClass  Container  =  m_model.createClass(  NS  +  "Container" ); 

/**  <p>A  container  is  listed  on  a  Bill  of  Lading.</p>  */ 

public  static  final  ObjectProperty  listedOn  =  m_model.createObjectProperty(  NS  +  "listedOn" 

); 

/*  Container  End  */ 

/*  EDI  Message  Start  */ 

/**  <p>  EDI  Messages  are  represented  by  the  EDIMessage  object.</p>  */ 

public  static  final  OntClass  EDIMessage  =  m_model.createClass(  NS  +  "EDIMessage" ); 

/**  <p>EDI  Messages  have  the  raw  message  associated  with  them.</p>  */ 
public  static  final  DatatypeProperty  message  =  m_model.createDatatypeProperty(  NS  + 
"message" ); 

/**  <p>EDI  Messages  have  the  message  set  associated  with  them.</p>  */ 
public  static  final  DatatypeProperty  messageSet  =  m_model.createDatatypeProperty(  NS  + 
"messageSet" ); 

/**  <p>EDI  Messages  have  a  sent  time.</p>  */ 

public  static  final  DatatypeProperty  sentTime  =  m_model.createDatatypeProperty(  NS  + 
"sentTime" ); 

/*  EDI  Message  End  */ 

/*  Event  Start  */ 

/**  <p>  Events  are  represented  by  the  Event  object.</p>  */ 

public  static  final  OntClass  Event  =  m_model.createClass(  NS  +  "Event" ); 

/**  <p>Events  have  a  time  they  occurred.</p>  */ 

public  static  final  DatatypeProperty  eventTime  =  m_model.createDatatypeProperty(  NS  + 
"eventTime" ); 

/*  Event  End  */ 
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/*  Shipment  Start  */ 

/** 

*  <p>This  class  represents  a  Shipment  containing  information  about 

*  containers  being  tracked.</p> 

*/ 

public  static  final  OntClass  Shipment  =  m_model.createClass(  NS  +  "Shipment" ); 

/**  <p>A  shipment  consists  of  containers.</p>  */ 

public  static  final  ObjectProperty  consistsOf  =  m_model.createObjectProperty(  NS  + 
"consists Of" ); 

/**  <p>A  shipment  is  defined  by  a  Bill  Of  Lading.</p>  */ 

public  static  final  ObjectProperty  definedBy  =  m_model.createObjectProperty(  NS  + 
"definedBy" ); 

/**  <p>A  shipment  has  Shipment  Legs.  </p>  */ 

public  static  final  ObjectProperty  happenTo  =  m_model.createObjectProperty(  NS  + 
"happenTo" ); 

/**  <p>A  shipment  has  Shipment  Legs.  </p>  */ 

public  static  final  ObjectProperty  has  =  m_model.createObjectProperty(  NS  +  "has" ); 

/**  <p>An  id  for  objects.</p>  */ 

public  static  final  DatatypeProperty  id  =  m_model.createDatatypeProperty(  NS  +  "id" ); 

/**  <p>A  shipment  is  referenced  in  EDI  Messages  </p>  */ 

public  static  final  ObjectProperty  referencedln  =  m_model.createObjectProperty(  NS  + 
"referencedln" ); 

/*  Shipment  End  */ 

/*  Shipment  Leg  Start  */ 

/**  <p>  Shipment  Legs  are  represented  by  the  ShipmentLeg  object.</p>  */ 

public  static  final  OntClass  ShipmentLeg  =  m_model.createClass(  NS  +  "ShipmentLeg" ); 

/**  <p>An  actual  time  of  arrival  for  a  shipment  leg  will  be  represented  by  actual ArrivalTime 
for  objects.</p>  */ 

public  static  final  DatatypeProperty  actualArrivalTime  =  m_model.createDatatypeProperty( 
NS  +  "actualArrivalTime" ); 

/**  <p>An  estimated  time  of  arrival  for  a  shipment  leg  will  be  represented  by 
estimated  ArrivalTime  for  objects. </p>  */ 

public  static  final  DatatypeProperty  estimatedArrivalTime  = 
m_model.createDatatypeProperty(  NS  +  "estimatedArrivalTime" ); 

/*  Shipment  Leg  End  */ 

//  Geo  points  are  created  using  the  following. 
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/**  <p>I  need  to  create  a  representation  for  geo  points.  This  is  the  geoNS</p>  */ 
public  static  final  String  geoNS  =  ’'http://www.w3.org/2003/01/geo/wgs84  pos#’1; 


/**  <p>Map  the  prefix  fro  the  geo  tag</p>  */ 

public  static  final  PrefixMapping  geoPM  =  m_model.setNsPrefix("geo",  geoNS); 

/**  <p>The  geo  has  a  point.</p>  */ 

public  static  final  ObjectProperty  Point  =  m_model.createObjectProperty(  geoNS  +  "Point" ); 
/**  <p>The  Point  has  a  latitude  value.</p>  */ 

public  static  final  ObjectProperty  lat  =  m_model.createObjectProperty(  geoNS  +  "lat" ); 

/**  <p>The  Point  has  a  longitude  value</p>  */ 

public  static  final  ObjectProperty  longitude  =  m_model.createObjectProperty(  geoNS  +  "long" 

); 

} 


2.8  Step  8.  Develop  RDF/XML  Representations  of  Instances 

<rdf:RDF 

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 

xmlns:xsd="http://www.w3.org/2001/XMLSchema#" 

xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 

xmlns:owl="http://www.w3.org/2002/07/owl#" 

xmlns:vcard="http://www.w3.org/2001/vcard-rdf/3.0#" 

xmlns:geo="http://www.w3.org/2003/01/geo/wgs84  pos#" 

xmlns:Shipping="http://domains.intervise.com/shipping/1.0#"> 

<rdf:Description 

rdf:about="http://domains.intervise.com/shipping/1.0#Shipment/KKTU772062.KKLUANR8002 

14"> 

<Shipping:consistsOf> 

<rdf :  Description 

rdf:about="http://domains.intervise.com/shipping/1.0#Container/KKTU772062"> 

<Shipping:  id>KKTU 7 7 2062</Shipping:  id> 

<Shipping:listedOn> 

<rdf :  Description 

rdf:about="http://domains.intervise.com/shipping/1.0#BillQfLading/KKLUANR800214"> 

<Shipping:id>KKLUANR800214</Shipping:id> 

<Shipping:referencedIn> 

<rdf :  Description 

rdf:about="http://domains.intervise.com/shipping/1.0#EDIMessage/GTN20090306  194350"> 
<Shipping:id>GTN20090306_194350</Shipping:id> 
<Shipping:message>&lt;BlMessage&gt; 

&lt;TransactionInfo  AcknowledgementRequested="false"&gt; 
&lt;MessageSender&gt;GTNEXUS&lt;/MessageSender&gt; 
&lt;MessageRecipient&gt;INTERVISE&lt;/MessageRecipient&gt; 
&lt;MessageID&gt;GTN20090306_194350&lt;/MessageID&gt; 
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&lt;Created&gt;2009-03-06T19:43:50.463-08:00&lt;/Created&gt; 

&lt;FileName&gt;INTERVISE20090306_194352932.xml&lt;/FileName&gt; 

&lt;/TransactionInfo&gt; 

&lt;BL  BLNumber="KKLUANR800214"  BillType="SeaWaybill"  CarrierScac="KKLU" 
MoveType="CYPToCYP"  Payment="Mixed"  Purpose="Completion" 

Sequence="l"  ServiceType="NoCFS"  Shipmentld="90406"&gt; 

&lt;References&gt; 

&lt;Reference  referenceType=''BookingNumber"&gt;KKLUANR800214&lt;/Reference&gt; 
&lt;Reference  Description="SERVICE  CONTRACT" 
referenceType="ContractNumber"&gt;GSN00083&lt;/Reference&gt; 

&lt;/References&gt; 

&lt;Voyage&gt; 

&lt;  V  oyageNumber&gt;  1 7E&lt;/V  oyageNumber&gt; 

&lt;Vessel  Code="9302619"  Country="LR"  Qualifier="Lloyds"&gt; 

&lt;Name&gt;YM  UNITY&lt;/Name&gt; 

&lt;/Vessel&gt; 

&lt;/Voyage&gt; 

&lt;Parties&gt; 

&lt;Party  Code="10013959"  Type="Shipper"&gt; 

&lt;Name&gt;DHL  GLOBAL  FORWARDING  (BELGIUM)  NV&lt;/Name&gt; 
&lt;Address&gt; 

&lt;AddressLine&gt;ANTWERPSEBAAN  56&lt;/AddressLine&gt; 

&lt;AddressLine&gt;2040&lt;/AddressLine&gt; 

&lt;AddressLine&gt;ANTWERPEN&lt;/AddressLine&gt; 

&lt;/Address&gt; 

&lt;/Party&gt; 

&lt;Party  Type="Consignee"&gt; 

&lt;Name&gt;FANCHENG  INTERNATIONAL  TRANSPORTATION  SERVICE  CO 
LTD&lt;/Name&gt; 

&lt;Address&gt; 

&lt;AddressLine&gt;8-9F.  218  WU  SONG  ROAD&lt;/AddressLine&gt; 
&lt;AddressLine&gt;SHANGHAI&lt;/AddressLine&gt; 

&lt;AddressLine&gt;P.R.  CHINA&lt;/AddressLine&gt; 

&lt;/Address&gt; 

&lt;/Party&gt; 

&lt;Party  Type= "Forwarder" &gt; 

&lt;Name&gt;DHL  GLOBAL  FORW ARDIN G&lt ;/N ame&gt ; 

&lt;Address&gt; 

&lt;AddressLine&gt;(BELGIUM)  NV/SA&lt;/AddressLine&gt; 
&lt;AddressLine&gt;ANTWERPSEBAAN  56&lt;/AddressLine&gt; 

&lt;/Address&gt; 

&lt;/Party&gt; 

&lt;Party  Type=  "Notify" &gt; 

&lt;Name&gt;DANZAS  Z.F.  FREIGHT  AGENCY  CO.LTD.&lt;/Name&gt; 
&lt;Address&gt; 
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&lt;AddressLine&gt;  14FLR, ORIENT  INTERNATIONAL 
FINANCE&lt;/AddressLine&gt; 

&lt;AddressLine&gt;PLAZA.  NO.  318  SOUTH  ZHONGSHAN 
ROAD&lt;/AddressLine&gt; 

&lt; AddressLine&gt;2000 1 0  SHANGHAI,  P.R.  CHINA&lt;/AddressLine&gt; 
&lt;/Address&gt; 

&lt;/Party&gt; 

&lt;/Parties&gt; 

&lt;Locations&gt; 

&lt;Location  Country="BE"  Function="OperationalOrigin" 

Identifier="BEANR"  Qualifier="UNLOCODE"&gt; 
&lt;Name&gt;ANTWERP&lt;/Name&gt; 

&lt;/Location&gt; 

&lt;Location  Country="BE"  Function="ContractualPlaceOfReceipt" 
Identifier="BEANR"  Qualifier="UNLOCODE"&gt; 
&lt;Name&gt;ANTWERP&lt;/Name&gt; 

&lt;DateTime  Qualifier="Actual"  TimeCode="LocalTime"&gt; 
2009-03-03T16:26:00.000-08:00 
&lt;/DateTime&gt; 

&lt;/Location&gt; 

&lt;Location  Country="BE"  Function="OperationalPortOfLoading" 
Identifier="BEANR"  Qualifier="UNLOCODE"&gt; 
&lt;Name&gt;ANTWERP&lt;/Name&gt; 

&lt;DateTime  Qualifier="Estimated"  TimeCode="LocalTime"&gt; 
2009-03-03T16:26:00.000-08:00 
&lt;/DateTime&gt; 

&lt;/Location&gt; 

&lt;Location  Country="CN"  Function="OperationalPortOfDischarge" 
Identifier="CNSHA"  Qualifier="UNLOCODE"&gt; 
&lt;Name&gt;SHANGHAI&lt;/Name&gt; 

&lt;DateTime  Qualifier="Estimated"  TimeCode="LocalTime"&gt; 
2009-03-26T1 2:00:00.000-07:00 
&lt;/DateTime&gt; 

&lt;/Location&gt; 

&lt;Location  Country="CN"  Function="ContractualPlaceOfDelivery" 
Identifier="CNSHA"  Qualifier="UNLOCODE"&gt; 
&lt;Name&gt;SHANGHAI&lt;/Name&gt; 

&lt;DateTime  Qualifier="Estimated"  TimeCode="LocalTime"&gt; 
2009-03-26T12:00:00.000-07:00 
&lt;/DateTime&gt; 

&lt;/Location&gt; 

&lt;Location  Country="CN"  Function="OperationalFinalDestination" 
Identifier="CNSHA"  Qualifier="UNLOCODE"&gt; 
&lt;Name&gt;SHANGHAI&lt;/Name&gt; 

&lt;/Location&gt; 

&lt;Location  Country="BE" 
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Function="OperationalBillOfLadingReleaseOffice"  Qualifier="UNLOCODE"&gt; 
&lt;Name&gt;ANTWERP&lt;/Name&gt; 

&lt;/Location&gt; 

&lt;Location  Country="BE"  Function="OperationalRelayPort" 

Identifier="BEANR"  Qualifier="UNLOCODE"&gt; 
&lt;Name&gt;ANTWERP&lt;/Name&gt; 

&lt;/Location&gt; 

&lt;/Locations&gt; 

&lt;ContainerGroups&gt; 

&lt;ContainerGroup&gt; 

&lt;Container  EquipmentNumber="772062" 

EquipmentNumberCheckDigit="2"  EquipmentPrefix="KKTU"  Type="22GP"&gt; 
&lt;Weight  Qualifier="Gross"  Units="Kilograms"&gt;67 1 4.0&lt;/W eight&gt; 

&lt;Volume  Units="CubicMeters"&gt;23.206&lt;/Volume&gt; 
&lt;SealNumber&gt;3721043&lt;/SealNumber&gt; 

&lt;SealNumber&gt;NO  SEAL&lt;/SealNumber&gt; 

&lt;Packaging  PackageType="Piece"  Quantity="51.0"/&gt; 

&lt;/Container&gt; 

&lt;Commodity  PackageTypeDesc="None"&gt; 

&lt;Weight  Qualifier="Gross"  Units="Kilograms"&gt;67 14.0&lt;/Weight&gt; 

&lt;Volume  Units="CubicMeters"&gt;23.206&lt;/Volume&gt; 

&lt;DescriptionLine&gt; 

METALLIC  LAMINATES  30  CANS  CHEMICAL 
&lt;/DescriptionLine&gt; 

&lt;DescriptionLine&gt;S  RESTRICTED  VINYZENE  IT  4010 
EDIDP&lt;/DescriptionLine&gt; 

&lt;DescriptionLine&gt;IMDG.CL.8  UN  3265  .  .  BOLTHING 
C&lt;/DescriptionLine&gt; 

&lt;DescriptionLine&gt;LOTH  HTS-CODE:  5911.20  =  4 
PALLETS&lt;/DescriptionLine&gt; 

&lt;DescriptionLine&gt;+  1  COLIS  8  PKG  HTS:  8504.40  7  PCS&lt;/DescriptionLine&gt; 
&lt;DescriptionLine&gt; 

DPR  7200B-48  ELECTRICAL  TRANSFORMER 
&lt;/DescriptionLine&gt; 

&lt;DescriptionLine&gt; 

S  BUSBARS  (32  PARCELS  LOADED  ON  5  P 
&lt;/DescriptionLine&gt; 

&lt;DescriptionLine&gt; 

ALLETS)  PREM  PLUS  GLOSSY  PHOTO  PAPE 
&lt;/DescriptionLine&gt; 

&lt;DescriptionLine&gt;R  HARMLESS  GLUE  HS:  35069100 
PLASTI&lt;/DescriptionLine&gt; 

&lt;DescriptionLine&gt; 

C  MATERIALS  (55  CARTONS)  MICROPUMPS 
&lt;/DescriptionLine&gt; 
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&lt;DescriptionLine&gt;(  14  CARTONS)  TOOLS  FREIGHT 
PRE&lt;/DescriptionLine&gt; 

&lt;DescriptionLine&gt; 

PAID  SHIPPERS  LOAD,  STOW  AND  COUN 
&lt;/DescriptionLine&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;Descr  INFO  [main]  (Messagelmporterlmpl.iava:304)  -  closing  the  JENA  DB 
connection. 
iptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;DescriptionLine/&gt; 

&lt;Marks AndNumbersLine&gt;426 180010  ROHM&lt;/Marks AndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;AND  HAAS  SHANGH&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;AI,  CHINA  STO  4&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;700297393  SEFAR&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;FILTRATION  SOL&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;UTIONS  CN-JIANG&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;SU  655079001-00&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;2  655 1 14001  -005&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;655 117001  DELT&lt;/MarksAndNumbersLine&gt; 
&lt;Marks AndNumbersLine&gt; A  ENERGY  S Y STEM&lt;/Marks AndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;S  SWITZERLAND  R&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;MA-86495/l-(l)&lt;/Marks  AndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;P.R.CHINA  INV.N&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;0.90157091,  711&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;0  SCHNEIDER  SUZ&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;HOU  DRIVERS  CO.&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;LTD  PO  4500892&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;032  CAL  COMP  JI&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;ANGSU  CHINA  1/1  &lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;REF  -  807179  J&lt;/Marks AndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;IANGSU  INTER-CH&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;INA  GROUP  ZHENJ&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;IANG  JIANGSU  CH&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;INA  1235413  123&lt;/MarksAndNumbersLine&gt; 
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&lt;MarksAndNumbersLine&gt;5268  -  1235270&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;BOSCH  POWER  TOO&lt;/MarksAndNumbersLine&gt; 
&lt;MarksAndNumbersLine&gt;LS  (CN)  CO.  LTD&lt;/MarksAndNumbersLine&gt; 
&lt;/Commodity&gt; 

&lt;/ContainerGroup&gt; 

&lt;/ContainerGroups&gt; 

&lt;KeyDates&gt; 

&lt;DeliveryDate  Qualifier="Actual"&gt;2009-03-26&lt;/DeliveryDate&gt; 

&lt;OnBoardDate&gt;2009-03-03&lt;/OnBoardDate&gt; 

&lt;IssueDate&gt;2009-03-03&lt;/IssueDate&gt; 

&lt;/KeyDates&gt; 

&lt;Authentication&gt; 

&lt;Name&gt;K  LINE&lt;/Name&gt; 

&lt;Date&gt;2009-03-03&lt;/Date&gt; 

&lt;/Authentication&gt; 

&lt;Totals&gt; 

&lt;Weight  Qualifier="Gross"  Units="Kilograms"&gt;67 14.0&lt;/W eight&gt; 

&lt;Volume  Units="CubicMeters"&gt;23.206&lt;/Volume&gt; 

&lt;Quantity&gt;5 1  &lt;/Quantity&gt; 

&lt;/Totals&gt; 

&lt;Contact  Phone="8006093221"  Type="Information"&gt;CUSTOMER 
SERVICE&lt;/Contact&gt; 

&lt;/BL&gt; 

&lt;/BlMessage&gt; 

</Shipping:message> 

<Shipping:messageSet>310</Shipping:messageSet> 

<Shipping:sentTime>2009-03-06T19:43:50.463-08:00</Shipping:sentTime> 

<rdf :  tvpe>http://domains.intervise.com/shipping/l.()#EdiMessage</rdf :  typo 
<rdfs:label>Inbound  Message  GTN20090306_194350</rdfs:label> 

</rdf :  Descrip  tion> 

</Shipping:referencedIn> 

</rdf :  Descrip  tion> 

</Shipping:listedOn> 

<Shipping:referencedIn 

rdf:resource=’'http://domains.intervise.com/shipping/1.0#EDIMessage/GTN20090306  194350"/ 
> 

</rdf :  Description> 

</Shipping:consistsOf> 

<Shipping:  definedB  y 

rdf:resource=’'http://domains.intervise.com/shipping/1.0#BillOfLading/KKLUANR800214"/> 

<Shipping:has> 

<rdf:  Description 

rdf:about=’'http://domains.intervise.com/shipping/1.0#ShipmentLeg/KKLUANR800214-r’> 
<Shipping:  actual  ArrivalTimo 

2009-03-03T16:26:00.000-08:00 
</S  hipping:  actual  ArrivalTimo 
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<Shipping:estimatedArrivalTimex/Shipping:estimatedArrivalTime> 
<Shipping:id>KKLUANR8002 14- 1  </Shipping:id> 

<vcard:ADR  rdf:parseType="Resource"> 
<vcard:Locality>Antwerpen</vcard:Locality> 

<geo:Point  rdf:parseType="Resource''> 

<geo :  latx/geo :  lat> 

<geo:longx/geo:long> 

</geo:Point> 

</vcard:ADR> 

</rdf :  Descrip  tion> 

</Shipping:has> 

<Shipping:has> 

<rdf :  Description 

rdf:about="http://domains.intervise.com/shipping/1.0#ShipmentLeg/KKLUANR800214-2"> 
<Shipping:  actual  ArrivalTime> 

2009-03-03T  16:26:00.000-08:00 
</Shipping:  actual  ArrivalT  ime> 

<Shipping:estimatedArrivalTimex/Shipping:estimatedArrivalTime> 

<Shipping:id>KKLUANR800214-2</Shipping:id> 

<vcard :  ADR  rdf :parseT ype= "  Resource  "> 
<vcard:Locality>Antwerpen</vcard:Locality> 

<geo:Point  rdf:parseType="Resource"> 

<geo :  latx/geo :  lat> 

<geo:longx/geo:long> 

</geo:Point> 

</vcard:ADR> 

</rdf :  Description> 

</Shipping:has> 

<Shipping:has> 

<rdf:  Description 

rdf:about=’'http://domains.intervise.com/shipping/1.0#ShipmentLeg/KKLUANR800214-3'’> 
<Shipping:  actual  ArrivalTime> 

2009-03 -26T 1 2 : 00 : 00 .000-07 : 00 
</S  hipping:  actual  ArrivalTime> 

<Shipping:estimatedArrivalTimex/Shipping:estimatedArrivalTime> 

<Shipping:  id>KKLU  ANR8002 14-3 </Shipping :  id> 

<vcard:ADR  rdf:parseType="Resource"> 

<vcard:Localityx/vcard:Locality> 

<geo:Point  rdf:parseType=,'Resource"> 

<geo :  latx/geo :  lat> 

<geo:longx/geo:long> 

</geo:Point> 

</vcard:ADR> 

</rdf :  Descrip  tion> 

</Shipping:has> 

<Shipping:has> 
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<rdf:Description 

rdf:about="http://domains.intervise.com/shipping/1.0#ShipmentLeg/KKLUANR800214-4"> 
<Shipping:  actual  ArrivalTime> 

2009-03-26T  12:00:00.000-07:00 
</Shipping:  actual  ArrivalT  ime> 

<Shipping:estimatedArrivalTime></Shipping:estimatedArrivalTime> 

<Shipping:id>KKLUANR800214-4</Shipping:id> 

<vcard :  ADR  rdf :parseT ype= "  Resource  "> 

<vcard:Localityx/vcard:Locality> 

<geo:Point  rdf:parseType="Resource"> 

<geo :  latx/geo :  lat> 

<geo:longx/geo:long> 

</geo:Point> 

</vcard:ADR> 

</rdf :  Description> 

</Shipping:has> 

<Shipping:referencedIn 

rdf:resource=’'http://domains.intervise.com/shipping/1.0#EDIMessage/GTN20090306  194350"/ 
> 

</rdf :  Descrip  tion> 

</rdf:RDF> 


2.9  Step  9  Repeat  Steps  1  to  8 

Execute  loop  until  all  business  entities  have  been  mapped. 
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